Have a mobile-first theme

[shish]

The current themes are desktop-first, with some tweaks for small screens; an explicitly mobile-friendly theme would be nice

(This is in contrast to, though could be done in parallel with, #804)

[sanmadjack]

I've been thinking about this myself. There are many toolkits out there to create guis that can conform well on desktop and mobile, but most are made with single-page web applications in mind. It'd be quite a shift for shimmie to support such a ui, at minimum it would need a much more robust API to access data from. What are your thoughts on all this?

[shish]

Thinking about it a little, I think the two approaches are different enough to warrant having two github issues for discussions, as there's no reason we can't actually do both approaches (the only limit being manpower to write the code):

• Build an API which covers every feature (#788), then have a single-page JS-heavy client-side app on top of that

  • Having an API which covers everything would be nice anyway
  • There are nice toolkits for building webapps which feel like apps instead of feeling like web pages
  • Created #804 for this

• Use the existing theme system, with a custom theme

  • All necessary changes can happen inside the theme, no modifications needed to the rest of the codebase
  • JS not required
  • Sometimes being "just a web page" is nice (Search-engine- / deep-link- / ancient-hardware-friendliness comes for free, etc)
  • Using this issue for this approach

[luanalatte]

I am currently going through my third iteration at a custom theme with responsiveness in mind. Still desktop-first but using css grids and flexbox it is easy to convert to mobile-first by flipping the media queries.

However, I just finished my first mockup and I'm currently stuck at integrating it into shimmie. Since themes pull already formatted HTML from php functions, and styles are applied by default, what would be the way to "start from scratch" and pull content into my layout instead of the other way around? Does shimmie currently force us to rewrite every single function that returns html from extensions and base pages?

[shish]

Does shimmie currently force us to rewrite every single function that returns html from extensions and base pages?

Sort-of -- the plan was that the HTML generated by Extensions would be very generic, as close to raw-data as possible, and then the theme+css would take care of doing whatever layout it wanted. In practice extensions have ended up containing more layout code than I'd like...

(I wonder how much work it would be to make a deliberate push for moving layout-specific code out of extensions - ie expanding the number of useful functions in core/basethemelet.php so we override a single "draw a table" function instead of needing to customise every extension with a table in it...)

[luanalatte]

(I wonder how much work it would be to make a deliberate push for moving layout-specific code out of extensions - ie expanding the number of useful functions in core/basethemelet.php so we override a single "draw a table" function instead of needing to customise every extension with a table in it...)

I'll keep an eye on that as I make changes to my theme.

We could maybe push those changes for small extensions first, then adapt the bigger ones later when the base is already there. Of course it would lead to some extensions using their own layout while some are already updated to the new form but I think it would be worth it.

And one could still override the extension's specific html functions so we would be gaining extensibility rather than replacing it.

I think the hardest work would be adapting the existing themes. Since in my case I only know how Warm works because I based my first theme in that.