Backend/Admin layout overhaul

this will also potentially connect with @myriam’s new big user, although that could also lead to building a separate customised admin interface that talks to database using API

1 Like

I think in our case there will be a separate producer front end (which might be something to think about more generally for OFN ;-)) but I think for hubs admin the current backend, with this improvement, will be good… I’ll discuss that soon with our contacts :slight_smile:

It seems like there’s a number of big players on the OFN horizon… I think the visual impression people get when they’re trying out the platform can make a huge difference, so I sort of feel like an admin UI overhaul might be quite an important goal.

2 Likes

Hello people of the past! This thread is from 2015 :slight_smile:
I want to move that menu to the left!

I think this is so important for OFN.
This is not just about the UX and ease of use, this is about humans being biased when they make decisions. And the looks of an app UI are a massive influence on decision makers minds.

I’d love to work on this one during some of my volunteer time this year. Even if just to add more details and investigations to it.

One very important dimension to this epic is the solidus/spree fork and the relation with the UI improvement of Spree v3.
Context: we are on Spree 1.3 now and will soon be on 2.0.4. I am sure we will get to spree 2.1 in 2019 because spree 2.1 will enable us to move to rails 4 (upgrading from 2.0.4 to 2.1 will be a much easier than from 1.3 to 2.0.4).
After spree 2.1 there are still 3 steps to 2.4. Spree 2.4 is where solidus was born.

The important fact is that the big spree UI improvement was in v3 and so, the UI improvement is only in Spree v3. so, the latest versions of Solidus still look like OFN.

The other dimension to this is that we have a lot of customization on top of the Spree views, so the de-defacing of OFN is important because more and more views are becoming OFN views and not spree views, that means even if we upgrade to spree v3, we would still need to convert OFN views to that layout.

So, even if we decide to stay with spree, not solidus, it will take a long time until we get v3 and when we get v3 we will still need to work on our views to make it a good looking thing.

So, these are all good arguments to decide that OFN backoffice UI will be OFN specific in the long run and not dependent on spree or solidus UI. This is important to put forward so we can start making changes that may be incompatible with future spree versions.

What do you guys think?

2 Likes

I have no UX expertise at all and I would say : who has objective UX arguments on whether this menu should be on the left ? @Rachel mentioned a couple of time that we would need to agree on big basic UX rules, and said we would need data also for that (cf matomo).
Yuko did some work on mobile UX for instance, but shouldn’t we have some general work on our backoffice UX ? Driven by Yuko or someone else, but with some expertise and arguments about why this should be here or there.
I agree that UX is an argument for choosing this software or another, but I don’t think our UX is that bad actually… I saw other softwares, they also have their pros and cons… I don’t know if I would put that as a priority but I’m happy to hear other arguments :slight_smile:

I have no UX expertise at all and I would say : who has objective UX arguments on whether this menu should be on the left ?

We cannot give UX opinion without user behavior info. So either we launch interviews in this field or we plug tools like matomo there. This is why I opened: Enable Matomo to measure backoffice and actions
(doing both would actually be the best way).

Once this is done we also need to make strategic decisions like: do we want the backend to be responsive?
If yes, the menu on the left will be necessary.
I had in mind that this would come with the next Spree updates but I didn’t had in mind the problems it raises, thanks for clearing that @luisramos0

So this can be the first step for an overhaul.
But at the same time I’m wondering: will a left menu change a lot the rest of the platform? Maybe having someone testing stuff could also be good. How did you wanted to proceed @luisramos0? Will you need some UI work to lean on?

There’s no right or wrong solution in terms of menu position, the menu on the left is a general industry tendency and it supports more vertical space for the app and less horizontal (this is good for most laptop/desktop screens).

Apart from the easier (single click) access to submenus mentioned by Rob above, there’s also the space that the top banner is currently taking with the OFN logo and “Logged in as”. Maybe we could work on making this banner smaller… that could be a lot easier to agree and implement. Has this been discussed?

Or shall we go for what Rob is proposing above? The screenshots look great don’t they?

Technically, I wonder if anyone has other opinions re moving from skeleton to foundation… @kristinalim @maikel @Matt-Yorkley @sauloperez ?

Thanks so much @luisramos0 for explaining the process and issues re: going to Spree 3 - this is the first time I’ve understood this. I wonder @Rachel - would you mind explaining what ‘do we wan thte backend to be responsive?’ means. (Sorry but seems like an important concept and I need to understand it.)

In terms of the UX - frankly, as a user working with other users with very limited experience with other similar software - I don’t see that simply moving the menu is a big advantage. I understand if left is an industry tendency - but our users aren’t very experienced in the industry to know this anyway. But - I also understand and support single click access – even without (so called) ‘objective’ user data - it seems to me making things with fewer clicks is a no-brainer that we don’t need to over-think or over-research. BUT - I’m interested in the other UX things - and perhaps making a longer term UX plan/strategy - so we can fit the steps in toward that? LIKE - small pop ups when you hover to tell you little tips etc. — that you can turn off once you don’t need them anymore. I love this when I’m learning a new app/software package. Second - I want to raise the question of ‘backend/admin layout overhaul’ for whom Our producer users (suppliers and simple direct to consumer shops) are really lost in backend complexity they don’t need. What if this backend admin overhaul targets more complex hub-type users, and we develop a plan for some kind of app-like interface (I have no idea what I’m taking about - just guessing here) - that a simple shop can do as a kind of cut down way of getting up a product list… ??? (sorry if my guessing is out of line - but we need to somehow embrace the fact that we have users with really different skill levels and needs - esp if we imagine this to be a global platform with farmer users in the global south one day…)

Thanks @sigmundpetersen - I can’t explain why I didn’t think to just google it. Sorry. I need my morning coffee I think. :sleepy:

Don’t worry at all @tschumilas you were right to ask, I shouldn’t have use that word like that sorry.

This explain briefly why the industry tendency is to have left menu : it’s clearer on smaller screens (you can make it totally disappear easily also).

What you explain is exactly why I propose we have some kind of analyze of our user behavior on the backend before taking large overhaul decision. We might be surprise - or not - by what comes up, but at least we would have a clear view. Maybe each instance manager already has this for its users, and it just need to be curated.

Or shall we go for what Rob is proposing above? The screenshots look great don’t they?

They do!

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:

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.

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

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.

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

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:

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.

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