Responsive Mobile Design

[Gazook89]

As other discussions are started about UI redesign, perhaps another topic to consider is mobile deployment and using responsive design elements. As mobile is definitely not the current target device I didn't think it appropriate to bog down the existing UI discussion with it, but rather consider this a 'far future' goal.

My understanding about why we don't focus on mobile is because some css only works on Chrome...? Specifically column breaks come to mind.

I think that even if not every formatting option is functional, it can still be beneficial to many to type out their content on their phones. On mobile it would only be possible to view either the editor or the preview pane at one time, toggling back and forth.

At minimum, viewing Share links on the phone should give a better touch-adapted UI than the full desktop UI.

[calculuschild]

One of the major issues with mobile is the text editor library we use does not play nicely with mobile. The CSS is not really as much of a problem.

However we could work on translating our drop-down buttons to bigger sizes or something on the share view since they get pretty tiny.

[G-Ambatte]

CodeMirror 6 promises Touchscreen Support; hopefully this will lead to a better mobile experience. However it does appear that CM6 requires some significant changes to update from CM5 - I know that the change to using offset integers rather than { line, ch } position objects will require changes to HB code.

[calculuschild]

CM6 is also still in beta. If you (or anyone else) wants to take a crack at making the upgrade you certainly can, since I think its mostly stable now. But until it's fully released this will probably not be a priority on my part.

[Gazook89]

As I said in gitter, I was having fun in Affinity with a mobile design and so I'm posting a screenshot here for posterity. I'm not sure this design is great, because certain elements like the 'left toolbar' might not translate well to desktop without lots of customization for the mobile/screen-size media-query. However, something like the 'left toolbar' does actually add more space for additional buttons, like "italicize" and "bold" for text manipulation.

This isn't absolutely comprehensive-- I didn't dive into the UI menus for the /edit/ page, and I didn't go into the /user/ page at all. Maybe I will later.

Colors can be decided later, and I did design my document so that there are 'global' colors linked to the various pieces so hopefully that is easy to do if I come back to this.

[Gazook89]

Maybe the most important question for mobile design is: use a mobile subdomain to present different content, or rely on the same content/domain but use CSS to present it differently for mobile?

Not sure if it's trickier to add a subdomain because we already have hb as it's own subdomain (https://homebrewery.naturalcrit.com). Would we do https://m.homebrewery.naturalcrit.com? Or https://mobilebrewery.naturalcrit.com?

My instinct is that using a new subdomain would be technically harder, but that using one responsive domain would be harder in terms of design, since it can be difficult to work the required responsive css into such full UI.

[Gazook89]

Maybe right now it's just small changes to the current domain, adapting the CSS for certain breakpoints for little fixes. Then later heavily consider a mobile subdomain to be paired with a CodeMirror 6 update, since that will boost touch interactions a lot. The two updates go hand-in-hand.

[5e-Cleric]

As a Front-End Developer, my instinct is to just use media queries for this, but it is true that a separate subdomain would be way better and would avoid messing up the site. This is the way

[Gazook89]

Here is a mockup of a "responsive only" design, meaning it doesn't rely on different structure for mobile vs desktop. It will change via CSS at certain breakpoints, hiding some elements like button label text and some entire navbar items like the changelog.

Most of the work would need to be done in the css. Some small changes in the HTML, though: The <nav> element would be broken into 2 or 3 elements. On desktop, those would be side by side so they would still appear as a single navbar on top. Using the magic of CSS Grid, the last nav element could be placed at the bottom of the window at a breakpoint.

The CSS for the dropdown menus would also need to adjsut with the breakpoint, so that they become drop-ups (...).

The User Name nav item would optionally show the user name depending on space available.

I think the CSS here will be fiddly to get right, but overall I think it's a good halfway point between our current setup and a dedicated subdomain for mobile.

[Gazook89]

This is a new mockup which makes some bigger changes to the top navigation bar. I haven't started on mobile designs for this one, but I think they would mostly follow the previous mockups.

Bigger changes here include dropping "NaturalCrit" branding entirely from the navbar, and abstracting "The Homebrewery" to just an icon. Clicking on that icon will open a dropdown with the website info, seen below. This is all a reflex against the current design which I think loses too much space to both names. Particularly since "NaturalCrit" is nothing more than The Homebrewery at this point. I think it would be reasonable to meet halfway and keep "The Homebrewery" and make that the trigger for the dropdown menu.

I also removed a lot of the icons we currently use. I think we got used to the idea that every button needs an icon, and we lose a lot of space as a result. Icons are possibly helpful for some users, but I think those same users might benefit more from native language support. I did keep icons for any button that navigates out of the website, such as to Reddit or Github. And I do think Icons will be needed when considering mobile design, but only for the dropdown trigger buttons.

The "File" menu gathers all the various document functions into one menu. This is more conventional and IMO more organized. It also takes 6 buttons out of the navbar and replaces it with one trigger button for the dropdown, meaning more space for Titles and longer Usernames. One downside is some items will take more clicks/hovers. Since we are mostly doing auto-saves, I don't think an extra click for other functions such as creating a new brew or creating a PDF is a big loss.

I only mocked up the Recent Brews option, which shows a two column set of lists. This is likely the only place there would be a two column popout like this and even this one is optional-- the two categories could be stacked as they are in the current design. The Save options would include a manual Save trigger, a Google Drive toggle, and the auto-save toggle.

The Help menu is unchanged, except adds another set of options for finding our communities on Reddit, Discord, and Github.

Finally the Account menu is also largely unchanged:

Overall this is just an effort to free up some space in the navbar. As more features get added we will likely need to do this organization anyway, but even currently it's pretty cluttered on my small-ish laptop screen, frequently popping to two lines if I don't have my browser fullscreen.

[Gazook89]

I have a branch with all of the above functioning (the nav bar and menus). And here is the snippet menu/submenus:

Not a huge change from what currently exists. Note that the editors/undo/redo buttons are absent. They have been moved to the bottom of the editor as tabs with full text labels which will make it unnecessary to tell users

"you need to paste that into the Style Editor, which is the paint brush icon next to the snippet menus."

The snippet menus themselves can now stretch the whole width of the editor which makes them easier to hit on mobile, especially since now it is also easier to scale their height up as well on small screens. Because the menus have the whole width, they could also be easily allowed to flow to a second row with Flexbox, though some issues remain with that: how well does two rows of dropdown menus work?

The menu's are also fully keyboard navigable using arrow keys, enter, space, etc and conform to WAI-ARIA specs. The whole snippet bar is a Menu Bar.

Finally, menus and submenus are no longer clipped by the splitView divider. They can overflow into the renderer pane.

---

Some further work on this particular piece (snippet bar) includes adding the Snippet Group icons in (text editor, images, tables, phb). Possibly adding some color back into it, though that might come at the very end.

And beyond the snippet bar there is still a lot to do, especially since i've focused on only the Edit Page but i'm trying hard to 'componentize' all this so in the actual /pages/ files there is less code. My main focus is still "Desktop", but to make it easier on mobile right now.

[5e-Cleric]

This looks like an appropiate project for my skills, for anyone else interested in working in this, i recommend using Polypane, it is a chromium-based browser meant for developing, and it is specially good for being able to display multiple different sized windows at the same time:

It is not free though.

[5e-Cleric]

Yeah, don't have time to work on this, my bad.