Design Proposal: Sandstorm Sidebar

[azirbel]

I have some new ideas for the Sandstorm sidebar, and thought I'd post them here to start a discussion.

Edit: Make sure you check out the second iteration of the design in the comments below.

Proposal TL;DR

Current default view	Proposed default view

Rationale

I was introducing my friend to Sandstorm the other day, trying to talk him into making an app with me. I showed him a demo of the Text Editor, and he was super impressed. Then he realized that there was no way to get rid of the big black bars around the app. That was a dealbreaker for him.

About two years ago, I was working at Addepar and we had a design that was pretty similar to what Sandstorm has now. We redesigned it because the black color was too overwhelming. See the blog post here. To put it simply, we made this change:

Old	New

We did this because black is a very strong color and draws your attention away from the important part of the app. The app felt restricted, crammed in, because of the dark sidebar.

I think we can do even better with Sandstorm. We can get rid of the top nav altogether.

This is an important issue, because (1) it's most people's first experience with Sandstorm, and (2) the navigation bars give Sandstorm apps a very distinct look and feel. I think it's worth getting this right early on so that apps can be designed accordingly.

Scope

I know a lot of people want to allow apps to run in fullscreen (no bars at all). I do too.

However, fullscreen has a lot of really tricky UI problems. For example:

1. Users might not know how to get "back" to Sandstorm
2. Important UI actions, like logging out, are handled by Sandstorm and wouldn't be available without a sidebar
3. Apps could mimic the Sandstorm UI and phish for users' information. (This is less of an issue than people make it out to be. It can already be done, and LastPass, whose sole purpose is security, has much bigger problems.)

Anyway, even though I think it should be possible to run apps in fullscreen mode, this proposal is far less ambitious. I think a good first step is simply rearranging the UI elements we have today.

Scenario

While reading, think about the following scenario:

I create a survey / poll / document and email it out to everyone in my company asking for feedback. The link takes them to an instance of my Sandstorm app, where they log in (maybe), read the document, and leave feedback (maybe). I am the only technical sandstorm user.

This is something I want to do right now. I think it's a common scenario, and implies that for most users:

1. They are disoriented. They don't know Sandstorm and don't know what the sidebars are for
2. They only have one grain open, and will not switch to other Sandstorm apps
3. They may or may not be logged in

   Room for improvement in current design

The current UI is good in a lot of ways. It makes it very clear which parts of the screen are controlled by Sandstorm, and enables all the common user actions. But it has a few issues, too:

• Black is a very heavy color and draws attention - but the user's attention should be on the app, not the menu
• The menus take up a lot of the screen
• The menus use a top header bar. Almost every app also has a header bar, which means that there are now two header bars. Vertical screen space is already limited, and Sandstorm makes it worse.
  • This issue won't be fixed by "designing apps with Sandstorm in mind", either. Many apps will still need their own header bar to provide filters, navigation, and other common actions.
• The Sandstorm menus have a lot of clutter, including actions that users will rarely need (debug log for the grain owner) and scary actions (delete grain)

As an illustration of the double-header-bar problem, take WeKan. I think WeKan is a really well-designed app, but it has a double header when used inside Sandstorm. Each header displays the same title. It makes sense for WeKan to display the title itself (and emphasize it), because it wants to keep the forum on-topic. It also uses the header bar intelligently for other purposes.

Proposed redesign

Overview of changes made:

• Change black to light gray. This grabs attention less, still doesn't clash with color schemes, and is probably easier to integrate with the look and feel of your app (if you want to). I think it's great if Sandstorm feels like a smooth extension of the app you are using.
• Move topbar menu items into the sidebar
• Reorder the sidebar to display items in order of significance. Hide most options inside of menu items.

I'd also propose that the collapsed view should be the default. I could be wrong on this one, but the idea is to make Sandstorm look insignificant for the users who have just been sent a link and will be visiting the app briefly.

Collapsed View	Expanded View

Another primary consideration of this design is to improve the experience for users who have only one grain open. I think this is likely a common use case, for the scenario above. It's also very reasonable to keep one app open per browser tab.

In this design, the grain switcher isn't shown unless there are multiple grains open:

Now to explain the design, from the top:

Sidebar	Explanation	Submenu
	Sandstorm menu. Here we put sandstorm notifications (like app upgrades), and have an option to go to Sandstorm settings. Keeping it at the top reinforces the Sandstorm brand and gives context to the rest of the page.	Shows notifications and global sandstorm settings.
	User menu. Shows the user's logged-in state, and their avatar (if there is one). Keep the focus on me! I am important! I host for myself! ;)	Shows user settings.
	Expand/collapse, like before. Also acts as a visual separator between the Sandstorm-level menu (above) and the Grain-level menu (below).
	The grain I'm currently using. It's too bad that this is duplicated between this location and the grain switcher below, but that's also how it is now. (The title is shown twice). It's nice to have the app icon and title here, because (1) it gives you context at a glance, and (2) is a logical location if you only have one grain open, and the grain switcher is hidden. Notice that if you skim down the sidebar, you see "I'm in Sandstorm -> I'm logged in -> I'm in X app", in that order.	Edit button to change the app title
	Sharing settings for the grain I'm currently using.	Sharing settings
	App settings for the grain I'm currently using.	Options currently in the topbar: debugging info, app keys, delete button, etc.
	Grain switcher. Comes up from the bottom instead of down from the top, to create visual separation between the app I'm currently using and the other apps. Also makes sense next to the "open grain" button below. Don't show these icons unless there multiple grains open.
	Grain switcher.
	App switcher / installer. This goes near the bottom because it's an uncommon action for "real" Sandstorm users, isn't used at all by guests, and doesn't provide context for anything on the page. It's a logical progression from "grains I have open -> open grain -> open/install new app".
	Help menu. For my poor coworkers who have never used Sandstorm, and don't know why there's a sidebar here. Hopefully they can just ignore it and focus on the app, but if they're curious, this menu can give some context on what Sandstorm is and how they can use it.	Context info and guides

Weak points

• The grain title is displayed twice in the same sidebar. This is weird.
• "The grain I'm in" is indicated both in the grain switcher and in the top of the navbar. This is weird.
• The gray I used may be too light. We should probably darken it just a bit.

  Related ideas (extensions)

• An argument in favor of true fullscreen grains: both Google drive and Dropbox paper do this. Each document is very isolated, and has a back button to the "folder structure" where you can organize your documents. This is analogous to fullscreen grains with a separate Sandstorm-driven management interface.

Drive doc	Drive organizer	Paper doc	Paper organizer

• Titles are less prominent in the new design. That's intentional. Some apps (say, document editors) are very "fine-grained" and reliant on titles. Other apps (say, Analytics or Fitness Trackers) don't even need a title: most people will only have one instance of them. Because of the varying significance, each app should be able to choose how its title is displayed. Therefore, Sandstorm should pass the grain title into the grain, so that apps can opt into displaying their own titles.
• "But why should each app implement their own title, a common and essential feature, and obviously needed by Sandstorm?" Ok, fair enough. We could also allow apps (in an app-wide configuration setting) to request that Sandstorm display a header bar for them, including the grain title. We could use this "request interface from Sandstorm" for other purposes too. Your app is made in a dark color scheme? Request that Sandstorm display the sidebar in black instead of the new light gray. When you switch to a grain of that app, Sandstorm would change its sidebar style. This would behave similarly to switching teams in the Slack desktop app.

  Wrapping up

This is just an idea.

I'm not a Sandstorm team member, and though I'm a big fan of Sandstorm, I may be missing essential use cases, misunderstanding the user base, and so on.

On top of that, I unfortunately don't have time to implement this design right now, even if everyone loves it.

So just take this as a suggestion, food for thought and/or inspiration. Take what you like from it! I hope you enjoyed reading.

[mnutt]

I like these ideas a lot. Having sandstorm bars in both directions does sometimes make it a bit confusing which parts of the UI are the app's and which are sandstorm's.

One thing to consider is mobile, where real estate (especially horizontal real estate) is really at a premium.

[azirbel]

That's a great point.

I wouldn't imagine that this proposal should change the mobile view - that would have to be a different design entirely.

I'm a big fan of Slack's mobile UX. One interesting thing they do is to put channels on the left, and an app-level menu on the right (both of which can be swiped to). I wonder if that concept would be useful here (e.g. grain switcher on the left, Sandstorm menu on the right).

[ocdtrekkie]

The biggest issue(s) I have is:

• You're using like three or four colors of light gray. I know from experience that if you aren't on a fancy MacBook, that means your entire interface is a wash of gray. (I specifically had to tweak my screen settings so that I could discern where buttons were on Google interfaces. I have no idea why designers don't realize this is a problem.)
• The same reasons you are advocating for a lighter Sandstorm interface is the major reason it shouldn't have one, actually. A huge number of apps and interfaces use gray-on-gray (or gray-on-something), and I think it'd be rather easy to not be able to differentiate to what icons floating around the left side of your screen are Sandstorm's.
• The definition of what is what on the sidebar is completely unclear. Spacing between the top and bottom (which isn't a guarantee depending on your screen size and number of grains) and the minor difference in icon size, is very confusing. I've been using Sandstorm since Sandstorm was a thing nearly, and I had no idea what your sidebar was supposed to do until I read your icon by icon breakdown.
• Given the above... the idea of starting minimized by default means that people who have never used Sandstorm will have even less of a clue than I did.

I am not generally opposed to the concept of getting rid of the top bar on desktops, but I think this needs to be a lot clearer and easier to understand.

[ocdtrekkie]

I should ALSO note, I'm a huge fan of the idea of the Sandstorm shell being flexible someday, so people can swap out for a design that suits them. But I think Nena has put the design in an incredibly good place right now.

[azirbel]

Thanks for the comments, @ocdtrekkie! Really appreciate it.

You're using like three or four colors of light gray

You're right that this is a bad idea. We would definitely want to bump up the contrast.

The same reasons you are advocating for a lighter Sandstorm interface is the major reason it shouldn't have one, actually.

This is an interesting question. Should Sandstorm try to stick out, flagging itself as something very different from the app? Or should it feel like almost part of the app?

I think somewhere in the middle. Sandstorm does take the place of many parts of an app, handling login and switching between grains. As an (aspiring, in-progress) app author, I'd like to design my app so that it feels comfortable next to the Sandstorm interface. That might mean some app-side color changes - which implies that Sandstorm should take a position on this issue before too many apps are written.

I think the design could do better to differentiate between the sandstorm sidebar and the app, and a black background isn't the only option. Maybe a medium-gray separating line between the sidebar and the app would be enough.

The definition of what is what on the sidebar is completely unclear

Probably room for improvement here. I tried to keep many ideas from the existing design (like the smaller rows for the grain switcher). Maybe we could use a consistent row height for all sidebar items.

Probably the icons are still unclear. I will think about it.

starting minimized by default

Thinking about this more, an icon-only sidebar is extremely confusing for new users. I think it's probably better to keep it expanded by default after all.

---

+1 to customizing the shell, but the new-user/default experience is probably more important than customization for advanced users.

I hope I didn't come off as critical of the existing design. It works well, and it does many things better than my proposed design (grain title is displayed in a logical place; indication of which grain I'm on is very clear; buttons to delete/configure the grain are above the grain).

I hope that some of the ideas here will be useful, maybe after a few iterations. Reducing the prominence of the sidebar, and giving more room to the apps, is something I personally would really like.

[ocdtrekkie]

@azirbel I think it's absolutely key that Sandstorm interface elements be distinct and obvious from app elements. What if it was hard to distinguish between the "home" button on your browser, and the "home" button to go to a website's home page? The web browser would be in a very sorry state if we couldn't distinguish browser from webpage. This is a good analogy for the Sandstorm platform. Except your browser lives in the cloud, and is viewed through another browser.

I definitely think the ideas are worth exploring, the top bar could definitely go if there was somewhere better to put that UI where it was still clear.

[kentonv]

I like the basic idea here. In the past I've been pretty stubborn about keeping the topbar, but your mockups do make things feel less constrained, and after looking at it I have to admit that our current UI now looks dated.

I agree we'll need to work on how the information at the top of the sidebar is presented to make it more clear. It's also too bad that this design makes it less clear which UI elements relate to the specific grain being displayed and which elements are "global", but maybe we can find a new way to solve that.

Jake is correct that it's very important that Sandstorm UI be clearly distinguishable from the app, for trusted UI reasons. I also agree with him that the color scheme should be high-contrast.

I think the sidebar does need to be expanded by default, so that people can learn what's there. Of course, once they shrink it, it should stick that way (we added such stickiness a few releases ago).

Let's keep iterating! I'm sure @neynah and @zarvox will have some opinions.

[mrflos]

Hi there!

I'm a big fan of what Sandstorm is trying to archieve, I'm willing to help but not an expert in UI/UX.. but I think that having 2 places taken by the Sandstorm UI is too much, and it brings too much contrast inside the browser window..

I like the app switcher sidebar, and on your proposal @azirbel, I think it's confusing to have the opened grains down, and special menu for current opened grain in the same place.

My suggestions (made together with other users tech/non tech) :

• remove the top horizontal bar
• add the user button / login / account options and notifications on the bottom of the sidebar
• access the the "share, restart, delete, download,.." options on right click (or long tap) on the sidebar icon
• access the the "share, restart, delete, download,.." options in the "My grains" page
• in the "My grains" page : make the columns sortable, and/or provide sort options buttons
• in the "Apps" page : Don't show "Most used" but provide sort options buttons like sort by name, most used, latest used, etc..
• maybe try the sidebar on the right side (or provide the option to choose left or right)

In an ideal world, I dream of an Sandstorm restful API for grains and app and users rights/admin, after it would be easier for me to work on different UIs mockups, provide Sandstorm webapps or Sandstorm phone app, but I'm sure the core devs are quite busy..

[ocdtrekkie]

@mrflos If anything, I think it's been a strong goal to make the ability to share grains more visible. Hiding grain options behind a right click would be really sad, I think.

I definitely want to see some of the "My Grains" page enhancements you mention though. The ability to rename/delete/share grains from that page is something I've wanted for a long time, same for the sorting options.

[azirbel]

Another big thanks for the feedback, everyone.

I've come up with a second iteration. Let me know what you think!

Updates:

• Sidebar is expanded by default
• Use a darker gray by default, increase the contrast
• Add a dark gray border on the right side of the nav, to separate the Sandstorm UI from the app UI
• Make all sidebar rows a consistent height
• Move sharing/app settings menus under the open grain icon
  • I like this idea, though I think the UI proposed here is still a bit strange. I tried to make the background white, but keep the right border for the submenu... I'm not sure it worked.

@mrflos, I think you bring up some great points about the grains/apps pages. I figured I'd just focus on the menus, but wanted to mention one thing - I think the "open grain" and "open app" distinction in the menus isn't very useful, and I'd prefer a single "open" button represented by the folder icon.

Collapsed state	Example menu pop-over

Bonus! I started thinking about a mobile design too. This one is pretty far into the "conceptual" realm; it's not pixel-perfect. I based it heavily on the slack mobile UI.

Current	Proposed	Expanded state	Example sub-menu
	The header bar is one big expand/collapse button	The menu slides down from the top, like it does now. The header turns white	Sub-menus slide in from the right side

Considerations for the mobile UI:

• Using the app icon in the header instead of the Sandstorm logo is a probably-controversial choice. I used the app icon because I think icon + title is a good way to keep context of "where am I"?
• I like how the Sandstorm menu is currently a fullscreen page which comes down from the top. Many mobile apps have menus on the left which you can swipe to. Because of this, Sandstorm can't do the same thing - it would be confusing to have two side menus which are accessed in different ways.

This will probably be the last iteration from me, unless someone on the Sandstorm team tells me they'd like me to continue working on it. I don't want to step on anyone's toes, especially since I'm sure @neynah could make an amazing version of this UI given some time to work on it. I imagine the core team is pretty busy.

The reason I've been working on this proposal is because I really want a Sandstorm UI that (1) has no topbar and (2) has less visual prominence. I'm hoping to show that this is possible, even if the design I've come up with here needs more iteration.

[ocdtrekkie]

@azirbel That seems like a pretty good way to arrange that, actually. I'm pretty fond of that. I might make the text and icon size of the sharing and settings options a bit smaller, because I think that's a better indicator of being a sub-item, but that's mostly nitpicks.

I am still vastly in preference of the bar being dark. This might be in the "please just give me a dark theme option"[1] territory though, I really hate white/gray interfaces. Your borders are much more distinct though, so the usability concern has been fairly well addressed.

[1] This is something Windows 8/10/Phone/Xbox has supported for a long time, and I'm amazed that in 2016, Android still doesn't have it (though it's been hinted at in Android 6 preview releases, then pulled). I really want a dark theme setting, which not only will affect my global UI (Sandstorm itself), but will be available for apps to see as well, so apps can choose to match my UI preferences automatically.

[ocdtrekkie]

The gap in the sidebar border did indicate to me visually that those icons were attached to the visible grain (like a browser tab!) but I would let that border gap span all three icons, again, like a tab.

Though, if the grain background was a different color than the sidebar, this effect would probably not really work either way.

[azirbel]

+1 to the dark-theme idea @ocdtrekkie.

I just realized that what bugs me isn't "the sidebar is black" at all - it's just the prominence of it. This looks fine:

The "sandstorm sidebar is like a browser" analogy is really good. In this case, I'd interpret it to say that the sandstorm sidebar should be light by default (like a browser). Of course, you might disagree on how we should interpret the analogy. I'm happy to assume that most apps are light by default, and we'll need to build a dark-theme configuration at every level of Sandstorm if we want it all to be consistent.

[mrflos]

I liked the second iteration from @azirbel , just the share and cog icons and text for the active grain could be smaller or inlined, in my opinion.

I had a crazy idea about the color of the sidebar, reading https://manu.ninja/dominant-colors-for-lazy-loading-images , it would be possible to use this technique and generate a transparent png based on the screenshot of current grain, so the sidebar background color would be always paired with the grain, it's like ubuntu's chameleon launcher that changes according to the wallpaper!

Sorry for this cool / crazy stuff!

[neynah]

@azirbel Thanks for putting the thought & effort into this! I think you've proposed some interesting ideas. I have a few comments for now and then I'll probably add more later. From an aesthetic standpoint I would personally love to simplify the UI and move all elements into the sidebar but from a usability standpoint I think it adds some complications we should consider carefully.

• We have discussed the possibility of removing the top bar by moving everything into the sidebar. Although it feels cleaner to have the top bar gone I have a number of concerns with this:
  • there's risk of confusing users as "Account settings" and "Notification" will no longer be in the top right (which is where they are commonly found in most UI). I would suspect that people would also not notice it on the left since there's additional noise due to all the other icons also being there.
  • we'll also lose the full grain name and that's an important thing to consider
  • space is limited so we'll also have to think about what happens when a user has many grains open
  • Admins will also need a way to navigate to the admin panel. If that navigation item will also go in the sidebar it could be problematic in terms of space. This then poses the question: "what happens when we have new actions / UI elements to add?"
• I like the idea of having grain actions attached to the open grain (as you've mocked-up) although I'm not sure if this would be less confusing to users than it's current location(in the top bar).
  • In some of the user tests, people have ignored the sidebar especially when the app itself has it's own sidebar.
  • If we were to add grain actions below the grain in the sidebar, I would suggest having all actions visible than putting them under "settings" since they will be undiscoverable there. I think it's better to have these actions smaller & take up less space per action than to hide them. Perhaps 2-per row instead of just 1 (and also smaller icon & text) which grants us more room to display them all. I'm not set on that but it's something to think about!
• Although it's "clean" to combine notifications with the Sandstorm logo, we also lose discoverability of notifications. I suspect very few users would guess clicking on the Sandstorm logo would display notifications. Another issue with this is (once clicked) logos also typically take users to whatever "home" is—with those expectations they will not succeed by clicking on the logo.

Yes, our mobile UI needs work and we haven't yet gotten around to improving our mobile design yet!

FWIW, my toes are fine. Unfortunately, we probably won't be taking action to do any major redesign soon (other than testing & identifying issues) but I appreciate the discussion here. It's valuable for us to hear about the friction people are experiencing.

I'm sure @zarvox will eventually have some comments as well since we work on the UI & UX together.

@mrflos Matching the sidebar colour with the grain is a pretty cool idea. It might be jarring for users switching between grains though. Perhaps the answer is to decide on dark or light theme by default, and also provide some presets / themes so we can ensure there is high contrast between the sidebar/topbar background and icons on top.

[zarvox]

First off, I'm impressed by the level of thought that everyone on this thread is putting into this issue! A huge thanks to @azirbel for taking the time to rethink what's possible, mock everything up, and write up this tome detailing the design ideas so well. Threads like these make me super happy about working on Sandstorm in the open with all you lovely people. :)

To throw my .02 USD in on a few of the critiques/proposals (paraphrased):

• "menus have a lot of clutter, let's hide/relocate less common functionality" - fair. I think that:
  • deleting grains should be moved to the grain list, both to reduce risk of accidental deletion, and to allow for aggregate actions. See https://github.com/sandstorm-io/sandstorm/issues/364#issuecomment-192445861 for more details.
  • perhaps backup generation should live there too.
  • webkey management should be folded into sharing (and possibly powerbox as well) - see https://github.com/sandstorm-io/sandstorm/issues/863#issuecomment-182534267 for very brief discussion there.
  • Sharing may not be possible/intuitive to put on the grainlist page as an aggregate action, since each app provides different roles that you might assign to the sharees, and your user might also have different permissions to different grains. I agree that we should provide a way to do logical grouping of permissions and long-lived access, but I could also see that being done via a "folder" grain, which in effect holds a sharing link to each of the grains, and when you share access to the "folder" people would be able to access each of the grains linked in that "folder".
  • that leaves Show Debug Log, and Restart Grain, both of which are more technical actions, and could be either hidden behind another level of menu, or something.
• "title should be managed by the app" - there's a few more wrinkles here that I feel I should mention:
  • As noted earlier in the thread, Sandstorm needs the title for its own display, but also every user sharing a grain may have their own name for the grain, so the app would need to receive the grain title from Sandstorm and have Sandstorm be the "system or record" for such a title.
  • Given the above, there's an ecosystem argument that apps that people adapt to Sandstorm would require more effort to integrate, and if we drop Sandstorm's display of the grain title then they might not show a title at all, which is arguably worse than the double-title outcome. So we should be careful if we want to remove the title from the
  • The grain title may or may not be considered trusted UI. I'll have to think about this more.
  • I agree in the ideal world, this would all be seamless. There's some tricky corners between here and there, and each integration is an ask from the community to spend the time and effort to maintain that integration in their apps.
• On the prospect of merging "open app" and "open grain" - there are some other features that still need some discoverable place to live:
  • uninstalling apps
  • uploading a new app
  • restoring a grain from a backup
  • reviewing the publisher of an app
  • installing a new app
  • I'm open to ideas on how to reorganize this. In my experience organizing pages by nouns works better than organizing things by verbs, so I'll suggest that we try to stick to that where possible.

I'm a little sad that Share Access becomes less discoverable in the proposed designs. In user testing, one of the things we've seen people struggle with is figuring out how to share something, so having less information scent within Sandstorm for that functionality bothers me a little.

Another thing we've observed in our user tests include a rather-strong expectation that clicking a logo in the top left of the screen will take the user back to the "root of the site". When that doesn't happen, users get lost. Users also tend to expect "sign in/out" and "my account" to be at the top right of the screen. I wouldn't call these complete showstoppers, but I am hesitant to change or remove affordances that users have learned from dozens of other sites without doing some tests to be sure that we're not making a prettier-but-less-usable-for-the-average-user design. We can easily add a sidebar item for notifications, but I'm not sure how to cleanly put account things at the top right, especially login (which is almost invariably the top right thing in a top-level nav). Perhaps we give apps some API for indicating to Sandstorm (maybe via postmessage) that the user has indicated intent to log in? But then what about apps that don't implement this sort of integration?

I think that while most users will probably want the collapsed sidebar most of the time, it should probably start out expanded, lest users have to explore an icons-only menu before they can discover any of Sandstorm's functionality. Maybe we should collapse by default for anonymous users? Today, we don't show the sidebar at all for anonymous users viewing through a sharing link, since there's little else they could usefully navigate to anyway.

I tend to prefer text labels to icons, or at least supplement icons with labels. Labels allow you to communicate a couple of useful things that icons generally don't, including whether this icon is meant to be a verb (button/action) or noun (link/route/place) as well as give a precise name and more information about what clicking this target will do.

Things I super-duper like and want to figure out how to make work, whether in implementing this design or a different one entirely:

• Clearer organization of things which are "global" vs "specific to my user" vs "specific to this view". This is not super clear in the UI today.
• Reorganizing the per-grain functionality.
• Reducing the "loudness" of Sandstorm's UI. While we get a lot of clash-avoidance from having a colorless UI, and I'm not entirely sure where I stand on the "Sandstorm should have easily-distinguished UI" vs "Sandstorm should blend into the app" spectrum, I agree that the black-next-to-white is so different as to be distracting.

Wow, that was a lot of words for two cents. I probably won't be able to work on this too much more in the immediate future, since we're trying to ship the new admin onboarding flow and admin panel, but I'm super happy to see all the ideas laid out in public where we can discuss and come back to them later. And @azirbel, consider me convinced that a less-prominent Sandstorm UI is possible and worthwhile, and quite possibly even one without a topbar, if we can figure out what to do with log in/out. :)

Again, thanks everyone for all the great input here, and feel free to continue debating the merits of various designs. :)

P.S. random note for people who like UX design: the card-sorting exercise is really useful for figuring out what things belong together! We used it to figure out what we should put together in the new admin panel designs.

[ndarilek]

Whatever happens with this, please please please incorporate ARIA from the start. :) Sandstorm is quite accessible these days, and talk of redesigns always makes me nervous about losing a11y ground in the name of shiny.

Thanks.

[ocdtrekkie]

Given that we currently have a reasonably familiar, decently accessible, fairly straightforward UI at the moment, my strong opinion is that if radical changes are made, the ability to change styles on the shell should be considered. So at minimum self-hosting admins (if not users themselves) can select a preferred style. I'd be happy to help with some of the additional workload that maintaining a legacy style might entail. (This would also be an additional feature for Enterprise hosters, who might want to brand/customize their style for their users.)

[ocdtrekkie]

@ndarilek I get super nervous pretty much anytime someone starts talking about redesigns to things I use.

[kentonv]

Random small thoughts (I haven't read 100% of the above but it looks like the discussion is being pretty productive):

• I like the idea of the grain-specific knobs appearing below the grain tab when the tab is active.
• Given that the title appears in the sidebar, perhaps it is in fact unnecessary for it to appear in the topbar on inside the app. I agree apps should have the ability to fetch the title for internal display but if many apps don't do so, that seems fine.
• Perhaps the sidebar color should be user-configurable.
• Note that switching between grains attached to different identities would presumably cause the user picture and name to change, despite it not being "under" the grain. I think that's OK.
• I do not think we should attempt to support multiple UI layouts at once. In addition to the code complexity issue, it's likely that we will repeatedly break alternative layouts as we make changes and fail to test them. Almost all of the UI would have to be tested twice, once for each layout, and manual testing is already a multi-hour process as it is. (Automated testing likely wouldn't catch a lot of the layout bugs that we'd see here, since Selenium doesn't know whet something "looks wrong".)
• I would consider any accessibility regressions to be release-blocking. We'd definitely get @ndarilek's feedback before pushing anything.

[mitar]

Can we also please move Sandstorm menu to the right? So that main content is on the left. You much less interact with the Sandstorm once you are in the app, so right side is much better for that.

[elimisteve]

I like the UI of @azirbel's designs but have a concern about UX: as a laptop/non-huge-screen user a fair amount of the time, the idea of having to scroll down all the time to access menu items that are below the bottom left of the screen instead of very conveniently available on the top bar sounds potentially painful, but I don't know if the left panel would be so tall as to cause this issue.

[matbrgz]

Heyy take a look at this https://tympanus.net/Development/OffCanvasMenuEffects/index.html#

[ocdtrekkie]

@MatheusRV The largest issue there would be... what happens when a Sandstorm app has a button in the top left corner?

[matbrgz]

@ocdtrekkie i could draw an interface, i'm UX designer.

[xet7]

What do you think about Themes feature Wekan is in process of implementing sometime? Could there be similar feature for Sandstorm?

[kentonv]

@xet7 I haven't looked at how Wekan is doing it, but the concept of "themes" scares me a bit in that I don't know how we'd avoid breaking themes whenever we added or changed UI elements in Sandstorm. I could only imagine supporting a static set of themes that live in the Sandstorm repo, so that we can extend and test them as needed. Though I'm also hesitant to do that due to the maintenance burden -- would rather wait until Sandstorm's UI has settled down.

People can, of course, implement "themes" in the form of browser extensions. But in that case it's on them if the theme breaks.

[xet7]

@kentonv

In Wekan it's still only on design phase. No code has been changed yet. That new theme shown there is done by just changing css locally, but AFAIK that theme is not finished yet and is probably broken because of changes in Wekan UI.

Now that I think of it more, having integrated feature for adding and changing theme is like Google's wontfix of Android draw-on-top that makes Android security broken. It's like implementing feature for shooting itself in the foot easily, having it reported as security issue many times, and marking it as wontfix.

The only systems where draw-on-top is disabled I know of are Qubes OS on desktop and Sandstorm on webserver.

Thanks for the idea of implementing "themes" in the form of browser extensions. I'll see how it works. For Wekan I'll rethink what is necessary to include built-in, so it still looks like Wekan.