UI Ideas

[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.

edit 6/25/25: adjusting the topic title to reflect a broader focus of UI rather than just mobile.

[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.

[Gazook89]

I wasn't sure if I should start a new Discussion but I've got "UI" related thought:

We could just use the same splitPane layout for both Share and Edit pages. The Edit page would have the Brew Editor, Style Editor, and Properties Editor in the left pane as it currently does. The Share page would have those same tabs, but only viewable, not editable.

---

This would basically eliminate the need for the /source/ route, because the source would be visible directly on the Share page in a split view with the Preview pane. It could retain it's separate "Brew" and "Styles" presentation, which is easier to look at anyway. And a "Clone this to New" button could be present, here, too. The /source/ route could be kept for whatever purposes people are currently using it for, but it wouldn't be necessary.

For me, when I help troubleshoot a brew, the first I think I do with their link is "Clone to new" so i can see what they are working with-- but if i could just view their markdown/css directly as they see it, I likely wouldn't have to clone to new.

The Properties wouldn't need to be up in the top Navbar with a floating dialog on the Share route, they would just be in the same spot in the Editor pane on the Edit route.

---

It would also unify the Edit and Share page layout, and give more logical options for where to put the Table of Contents Navigation-- just added as another tab that is again viewable in both the Edit and Share routes.

[5e-Cleric]

not against or in favor, but i don't think it is good UX for people that only want to see the content.

[Gazook89]

There would just be a button that opens or closes the panel. And, it would still be resizable like it is currently. Basically...just like panels in VS Code. The default/starter view on Share could be that the panel is closed.

[Gazook89]

Today in discord:

As a Homebrewery user trying to learn formatting, not having the option to see both the source HTML and the document when viewing another user's homebrew gets difficult. Something I'd love is the ability to do so without having to Clone to New.

[Gazook89]

Is the HeaderNav better as something that layers above the Preview Pane, or should it be the full pane height and reduce the width of the iframe?

When you have it open, do you intend to navigate quickly and want the HeaderNav box to disappear once you click? Does it bother you if it's covering some of the brew, like this?

Or do you want it to stay open until you dismiss it, and not cover the document itself?

[5e-Cleric]

It is great as is, we could use more popups and less permanent space menus. Like the properties panel, it could perfectly be a settings popup.

[Gazook89]

Two ideas I just want to write down:

Multiple panes beyond just 'code / preview'. Allow opening each editor as it's own pane so you can view Brew text, CSS, Snippets, Properties all at once if you have the screen real estate to do so. Adjust the splitPane component to have x number of panes which can be created, closed, or collapsed as needed.

"Help" panel: A panel or pane that can be opened that gives basic information such as commonly used MArkdown syntax, beginner CSS tips, how to use Inspect Tool, and links to further resources. Doesn't need to go into huge depth, but just establishes basic first steps and guides users to better resources.

[5e-Cleric]

So, something akin to codepen?

Or JSfiddle: