Skip to content
This repository has been archived by the owner on Oct 2, 2018. It is now read-only.

[Strategize] Firetext on Desktop #203

Open
ferndot opened this issue Nov 7, 2014 · 12 comments
Open

[Strategize] Firetext on Desktop #203

ferndot opened this issue Nov 7, 2014 · 12 comments

Comments

@ferndot
Copy link
Member

ferndot commented Nov 7, 2014

Firetext is badly suited to the desktop platform right now. We need to decide how we will revise the app's architecture to support a larger form-factor.

Decisions:

  • UI
    • Media query scaling + Web components

Still needs to be discussed:

  • File system:
    • "Upload" files?
    • Use filesystem API?
    • Use LocalStorage?
@ferndot
Copy link
Member Author

ferndot commented Nov 7, 2014

For the UI issue, I am strongly gravitating towards providing separate html layouts for desktop and mobile. The problem with this is that we would have to maintain both, and create separate scripts that can update each layout.

Media queries are nice, but they get messy, and there is only so much that one can do without updating the layout.

Another idea is to have a central layout file (index.html) which contains HTML common to both, and insert desktop/mobile "components" based on the device.

E.g.

<body>
  <div role="region" id="edit">
    <component name="editor"></component>
  </div>
</body>

@twiss
Copy link
Collaborator

twiss commented Nov 7, 2014

So I guess this depends on #190 and #204.

Do you see any major problems with the current UI? I think if anything needs a different UI between desktop and mobile it would be the editors themselves, I think the current Firetext UI is fine. (While thinking about it I came up with #207, but I don't think that warrants a separate UI?)

@twiss
Copy link
Collaborator

twiss commented Nov 7, 2014

For the UI issue, I am strongly gravitating towards providing separate html layouts for desktop and mobile.

Hm, alright. I'll think about it more. Maybe we could indeed create (or use?), e.g., a "menu" component which is different on desktop and mobile.

@twiss twiss mentioned this issue Nov 7, 2014
3 tasks
@Ryuno-Ki
Copy link

What about using templates?

@ferndot
Copy link
Member Author

ferndot commented Nov 19, 2014

@Ryuno-Ki: maybe this could be solved simultaneously with #208 by using web components?

@Ryuno-Ki
Copy link

Discovered today on Twitter:

<script>
  if ('registerElement' in document &&
    && 'createShadowRoot' in HTMLElement.prototype
    && 'import' in document.createElement('link')
    && 'content' in document.createElement('template')) {
    // native WebComponents supprt
  } else {
    document.write(
      '<script src="bower_components/webcomponentsjs/webcomponents.js"></script>'
    );
  }
</script>

Credits goes to @geelen. People are asking for necessary on Twitter.

@ferndot
Copy link
Member Author

ferndot commented Dec 12, 2014

Thank you @Ryuno-Ki. That will be useful.

@ALL: I have tinkered with the CSS, and got Firetext to look like this on the desktop. What do you think? If you like it, I will open a pull request:
screen shot 2014-12-11 at 11 13 54 pm

@Ryuno-Ki
Copy link

I'd expect a border around the document.

@twiss
Copy link
Collaborator

twiss commented Dec 12, 2014

Thanks for getting the filename in there. My first nitpick would be that you should rotate the arrow icon here, too. Also, now that I'm thinking about it, it might make sense to animate the dialog from the direction of the toolbar (and arrow).

@Ryuno-Ki well, or maybe some box-shadow?

@ferndot
Copy link
Member Author

ferndot commented Dec 12, 2014

To make this easier, I am thinking of reworking the tab system. A side effect of this would be the removal of non-zen-mode on mobiles (#234). We would have to figure out a good location for the document name on mobile as @twiss suggested.

What do you think?

@Ryuno-Ki
Copy link

@twiss shadow would work, too. Anything, which "lifts" the document from the background.

@ferndot ferndot mentioned this issue Dec 12, 2014
@ferndot
Copy link
Member Author

ferndot commented Dec 12, 2014

So, am I correct that we have decided upon media queries + web components for our desktop interface? I have split the implementation discussion for the desktop UI into #258.

The next thing we need to discuss in this issue is how to store files. Some options:

  • "Upload" files
  • Use filesystem API
  • Use LocalStorage

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants