Replies: 9 comments 11 replies
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 ( 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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 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. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.











Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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.
Beta Was this translation helpful? Give feedback.
All reactions