Backend/Admin layout overhaul

ux-overhaul
Tags: #<Tag:0x00007f1af260e7a8>
#21

interesting @tschumilas this is really calling for a conversation about the UX of the backoffice and how users interact with it.

in terms of the menu layout suggested above, what I get is that no one is against this change, and that’s a very good first step :slight_smile:

0 Likes

#22

Should we move the menu to the right?

Yes. Rob did great work and it’s a shame it has been unused for such a long time. Everybody agrees it looks great. Thank you @luisramos0 for volunteering! :heart: Do you have Rob’s branch?

What about Spree upgrades?

Thank you for summarising the possible impacts. I would vote for creating our own admin interface and eventually ditching spree-backend.

Should we move from Skeleton to Foundation?

Yes, the backend should use the same as the frontend.

0 Likes

#23

Awesome @maikel. Thanks for the encouragement!
Yes, with the “de-deface project” I think it’s becoming clear we will go our own way in terms of backoffice UI. And that eliminates one dimension of the spree/solidus question. And probably makes solidus more attractive for us (as spree v3 new UI becomes a considerable upgrade barrier without the benefit). We will see…

The branch must be this one:

I’ll rebase, have a look and post here my evaluation of how difficult it would be to get it ready to go.

1 Like

#24

I’m wondering how Rob design interact with Enterprise setup menu, which is also on the left.
To be honest I don’t know if we want the whole backend to be responsive… that’s a discussion we need to have. But I agree with @tschumilas that the priority for me is not UX but “cascading complexity”, just show the complexity a producer need, not the whole shit of possibilities. We started doing that by opening subscription only for some hubs. Maybe we should list the features and “toggle them” to activate / deactivate them upon request instead of showing to everyone.

0 Likes

#25

Yes! This would make me so happy! We could gain a huge amount of horizontal space as well with a responsive layout that’s not fixed in a 960 grid surrounded by whitespace on both sides:

1 Like

#26

So, I rebased the branch to latest master and it works, it’s not a lot of code.
Some pages look good others will need some changes. I’ll definitely explore this further to see if this would actually be something that we could deliver with not too much effort.

This morning on my computer with latest ofn version:

0 Likes

Focusing in for the first half of 2019 - a proposal for the global community
#27

Thanks a lot for your detailed report @luisramos0. I wonder however what’s the scope of that branch from Rob is just adding that left-side navbar?

The concern I have with any efforts on UX/UI is the lack of expert design feedback. Most of the pitfalls we encounter in the current design is due to devs doing what they are not generally good at. I’m too used to seeing it this in all sorts of projects.

In the same vein, we can’t ignore the impact of a UI change like this one will have on our users. IMO it has to be a well thought move and bring measurable improvements, if we decide to ship it. Redesigning it’s nothing we can do every day, so we can waste the opportunity.

0 Likes

#28

I am really happy I am not one of those “devs” because I absolutely love doing UI/UX work!

yes, I totally agree. we need to do this properly.
We need to see if moving the menu would be a possible intermediate step. Because this will require changing some other UI components for sure.
I’ll explore a bit more and report what would be the impact of such a change.

1 Like