A new admin interface for OFN

[Matt-Yorkley]

Yes! That’s basically my number one wish for OFN at the moment. It’s been discussed before but wasn’t considered a higher priority than the other things in our current roadmap. It would be great to use a framework to make building beautiful UI elements easier. I was thinking last of week about doing a spike on this.

We’ve had general agreement that an admin interface update, moving away from Angular, decoupling from Spree etc would be great, but they would require a lot of work. We currently have a full pipe and limited capacity, and we have processes for prioritising work and new features…

That being said, I’m very excited!

[Matt-Yorkley]

We have a lot of functionality and logic tied up in Angular code at the moment, which is probably the main thing that makes this a large job instead of a relatively small one. I’m wondering if there’s a way to split this into smaller phases instead of tackling everything at once? Like keeping some of the Angular in certain pages whilst moving to the new interface?

[Kirsten]

I may be wrong here - but I wonder if there is an opportunity to tie this to existing priorities. For example, there has been discussion about the first feature from Network 2.0 that we want to do - allowing creation of own copy of a product/variant. I think that we talked about this being a new version of the products and/or inventory page which started with this new logic . . does that ring bells @Rachel @luisramos0 etc? If so, this could be a candidate for two birds with one stone? i.e. we could progress the work on designing that, with a view to setting ux style for new backend, and @jonleighton could potentially work on the prototype as first project in this new system?

[luisramos0]

Yeah, it’s great to see your commitment @jonleighton

Yes, we wish we had a new admin UI, this item here represents the same problem, with a different solution: Backend/Admin layout overhaul
In this other post, we try to do what both spree and solidus did, revamp the existing UI in some way without having to re-write all pages.
The main problem with it, and this post here, is that, although highly desirable, this is not close to the top of our priorities right now.

This proposal here is a multi-year project and, as you correctly mention, this would require a huge amount of effort from the community in terms of Product (defining how this new app would work is a lot of work), Dev (code review and coding it in case you dont complete it), Testing and, most importantly imho, Code Maintenance (more code means more time/money goes into maintenance.

I think the main factor that makes me say “let’s not do this please” is our main constraint: lack of time, particularly dev time. Also, I think this would need to go through the normal voting process where instance managers vote in this against the other priorities.

So I try to offer alternatives:
1 - what do you think about supporting Backend/Admin layout overhaul?
2 - following up from your great idea of replacing the UI for certain user profiles: instead of replacing/improving existing functionality, what if we build extra functionality, for example, creating a new page specifically for supporting the packing process for farmers, that works on mobiles so it can be taken to the warehouse? this is just one example. (@Kirsten I follow you here but I dont think network is a good candidate because it’s a core part of the app. I think it would be very challenging to built something so core to the business model in parallel…)
3 - what if we rebuild the frontoffice and get the Mobile epic done in this manner? I’d support this mainly because it’s a task around 10 times smaller than rebuilding the admin UI.

In summary: I think starting a new huge project to rebuild the admin UI is not close enough to top priority and would be a step too big for our legs.
I think this last option “do it but in the frontoffice” can get some traction from the community mainly because it’s already a priority and I think it would make sense in terms of tech strategy: 1. to separate frontoffice from the API and 2. validate a more modern frontend tech stack (replace outdated angularJS).

I hope this helps. It’s great to have you around!

[Rachel]

Thank you @jonleighton for this proposal

I believe Luis has sum up most of my thoughts so far

@Kirsten yes for the network feature we have talked that it was a good opportunity to do a new version of our product page and making it reading for mobile. But what we also said - and I think this applies also here - is that we need to do some UX work beforehand. This is such a massive work that we also agree that this would be paid work in order to keep momentum and to include as many user feedback/interviews as possible (given we don’t have analytics in the backend). That’s why I’ve met with Yuko: in order to get a quote. But we didn’t move it forward despite our meeting in Barcelona, other priorities came through…

[sauloperez]

I’m not going to add much. I hear everyone’s opinions and I bet we all mostly agree.

Personally, I see this as an exciting step forward that touches on a very deep topic

This is likely to put off potential new users of OFN, as well as increase the burden of support queries.

but it feels daunting at the same time. To me, it’s like we struggle a lot to change the product beyond the surface, although we’re improving. And this inevitably brings fear and conservativism.

So, I say: let’s keep discussing and perhaps start from @luisramos0 points, hear the high-level ideas and goals of your proposal @jonleighton and split it into parts to see how we can make things fit together.

[Kirsten]

I understand and agree with all the above. I also had a conversation today with a potential user who was really values-aligned and really really wanted to use us, that ultimately went with something else (Square) because we can’t really deliver the supply transparency which is the thing he really believes in.

Is there a reason we can’t move forward on the UX for the new product page? and then potentially build / run in parallel? and do it in a way that makes creating and managing products from mobile happy and awesome? and run it in parallel until we retire the old one? I really thnk that cracking this network thing is critical, and we actually have a good plan … and if we could start to progress it with some added muscle for a while it would jump us forward a whole lot . .

[Rachel]

Is there a reason we can’t move forward on the UX for the new product page?

Funds? But I can ask Yuko when the quote will be ready so we can have an idea of the budget needed.

[luisramos0]

I’d like to share that I got really excited about this project after Maikel’s saying it would be ok if we manage to integrate it with the existing UI.
If we can find a way where the pages of new UI can replace the existing UI, instead of having 2 apps and having to migrate users over a very long period of time, we would be able to release the new UI within the old UI. This is called the strangler pattern.
Conditions for this:
A - the new UI cant be totally disruptive compared to the old one, we need to keep it blueish for example, so that users dont feel they are jumping between 2 apps (although actually they are).
B - we need to find a tech way to integrate the two UIs.

Regarding B:
I have done this twice in the past, once (a reports distribution solution in a bank) we used an iframe for the transition, the old code would render an iframe with the new pages from the new app. Eventually we removed the iframe as all pages were replaced. The other case (an email delivery solution in a digital marketing company) was a simple html div where the old code was calling the new code to render a specific div in the page (this required some tweaking to make the html of both apps compatible).

I think this is feasible in OFN, we need to find a tech solution for it and we would need to decide if we 1. render the old app inside the new app or 2. render the new app inside the old app. For option 1 we would start by rebuilding the menus.

This is probably the way to go about the future of the admin UI, even if not now. I dont think we will ever upgrade angularjs 1.5

[Kirsten]

I would really like us to be moving this even if we can’t get in dev pipe yet, because it really is so critical to our value proposition

[Rachel]

I’m sorry but I can’t keep getting back in my head to the discussion regarding things some instances or users would love to put money on.

We agreed our pipe was the only way to get things done. I really wonder if it is not the same case here.

So don’t get me wrong: I’m not saying I don’t want network or admin UX to happen. What I’m saying that I think it needs to be prioritized in the pipe.

Even if we don’t touch the UX part, there will be product, testing and code review to do.

So I don’t see the difference between a scenario where a new developer volunteer his time, or someone finding a new dev to work on something unprioritize by the community and paying for it… I feel like we end up with the same problems we want to avoid: maintenance, unfinished work, even slower pipe…more frustration.

I know it would feel good to say we start to work on those things. But it won’t mean we will finish it. Being able to finish things should be more important than to start them… And in order to finish work we need to set priorities or to set specific people on it.

[danielle]

I would really like us to be moving this even if we can’t get in dev pipe yet, because it really is so critical to our value proposition

If it’s critical to our value proposition then it should be prioritised in the pipe. I think we need to have that conversation about where it fits alongside of the other things we’ve prioritised.

Which means discussing it with the global hangout group and having people vote on it vs the other things to determine exactly how critical the crowd believe it is compared to the other things already there.

So, we bring to the crowd on Tuesday the idea of having a POC done to answer the questions of a) how could we improve the order management page, and b) can this new UI be integrated into the existing (as raised by @luisramos0 above), have this voted on in terms of priority and then get to it if it’s considered important.

@Kirsten and @Rachel this means that we’ll be following the process, but we’ll also see its criticality for the broader group by seeing where it’s voted in.

Ping @jonleighton - we’ll be bringing this idea to the global hangout tomorrow night Melb time for discussion, would be lovely to see you there

[jonleighton]

I’ve been mulling over the idea (from @luisramos0) about how to build out a new interface inside the existing one. I do broadly think it could work and would be a better plan than building an entirely new interface alongside the existing.

Basically the idea, as I understand it, is to have the new and old pages share the same layout shell (header, nav, footer…), but they would diverge in terms of look and feel within the body of the page. This would enable us to incrementally replace legacy pages with redesigned ones, until the legacy ones are eventually completely removed.

I think it would be sensible to redesign the “layout shell” using the new CSS framework as the first step in this, and then host the legacy pages within the new shell. The advantages I see in doing this are:

• Avoid constraining redesigned pages with legacy styling
• A chance to rethink the main navigation, which feels rather cluttered and unstructured to me
• Allow the new pages to be fluid-width to make better use of screen space for information dense pages

To feel sure that it would work, I’d need to do a code spike, but I can’t see any fundamental problems with the idea. (Albeit that there may be some pain around getting the legacy CSS to play nice with the new CSS on the legacy pages.)

All that being said, my feeling after our chat about this whole thing in the product curation meeting last week was that it’s probably best not to pursue this given the spectrum of opinions on it and the lack of resources in OFN generally. I’m also looking at my priorities for the new year and feeling unsure how much time and energy I’ll be able to dedicate it. But, if there is definite enthusiasm for redesigning a single page/section as a first step (such as the orders page) per the above strategy then I’m not ruling it out, so I’m happy to continue the conversation.

[luisramos0]

excellent Jon, thanks for your analysis!
What I like about this approach is that is feels like the way to go anyway, now or later.
It would be great to have your contribution towards this project!

[Kirsten]

I am definitely excited about redesigning a single page / section (i.e. potentially orders) as per above strategy. I am a little unsure about how complex redesigning the layout shell would be before we could do this . .

are we basically just talking about this bit?

[jonleighton]

are we basically just talking about this bit?

Yep, the stuff that doesn’t change across different pages.

[luisramos0]

I think we must take this step forward as part of the network feature. Most likely we will need to build a completely new and complex page (product finder) or maybe two (a replacement for products list/inventory page).

By “this step” I mean, we need to use this as an opportunity to define and start implementing our UI tech strategy for the future.

I just add another close look at tabler. @jonleighton I wonder what are the pros and cons of relying on tabler. Would this be a dependency we would keep upgrading and adapting to? I see you have put it in vendors in your branch, I wonder if this would not be upgraded and we would be tweaking these templates as we go. That would mean the pros would be:

• freedom from it as a dependency
• a good head start compared to building something from bootstrap only

I cant see any con, I wonder what are the alternatives to tabler apart from basic bootstrap.

We currently use foundation which I think is the main alternative to bootstrap in the market.
We are on foundation 5.5.2.1 from May 2015, we could simply use latest foundation 6.5.3.0 to build the new UI.

This is tightly related to the UI framework we will be using (I see tabler has projects in react, angular and also vuejs). I also posted in the UI framework upgrade thread just now.

[jonleighton]

I wonder what are the pros and cons of relying on tabler. Would this be a dependency we would keep upgrading and adapting to? I see you have put it in vendors in your branch, I wonder if this would not be upgraded and we would be tweaking these templates as we go.

IIRC I vendored it because I couldn’t find an easy way to pull it in as a dependency.

It would be worth considering alternatives to tabler. I had a look around at the time and felt like it was a good starting point but I’m sure there are other options.

I think something like tabler is a good approach to get a good-looking UI thrown together pretty quickly. But you’re likely to hit up against its constraints and need to implement customisations in places. Which would probably make upgrading a risky business anyway, so perhaps vendoring and ‘owning’ the dependency is the best approach anyway. (It’s not like you’re going to need to perform security upgrades in this case.)

Using something a bit more basic (e.g. Bootstrap, Tailwind, …) would likely result in a leaner and perhaps more easily maintainable end product, but would require more input from a designer (to get something that works well) and more up-front dev time. So there’s a trade off there.

[sauloperez]

I haven’t checked Tabler but although I’d love to build a good-looking UI that provides top-notch UX, it’s something we can’t really afford in the midterm IMO. I would lean towards adoptiong an existing solution.

It’s been just now that we’ve got design input and guidelines but the resources are very scarce on that end. We want to increase them but I don’t think we’ll have the capacity to develop a UI from scratch. In terms of dev, we would also need a bit more expertise, although I have no doubt we would learn along the way.

“Owning” Tabler or whatever other pre-cooked UI seems a far safer bet than it was with Spree. I agree. I wonder how feasible it would look to work on top of it for someone like Yuko or @Mario. Thoughts?

[Mario]

Thanks for looping me in My 2 cents on this
I’m personally a fan of using frameworks over reinventing the wheel, unless it’s strictly necessary or the product requires really new technology, so for me having a framework that allows to go custom when necessary is usually a good choice.
Specifically for OFN, I consider the admin side as a functional tool, where efficiency and ease of use are primary. It’s a table-based software, and I guess it’s going to stay like that in the future.
Neither bootstrap nor foundation have advanced table patterns. I spent a bit of time looking at separate libraries for table mgmt but couldn’t find anything as advanced as vuetify. What I like about it is that is based on Material Design, which is a design system with some solid thinking behind it, and a huge user base, familiar with its components and look and feel. And obviously, given the website has a massive amount of interactive examples, it makes it easier for a contributor to explore its modules, play with them and assess which are more suitable. Mobile is extremely well supported too.

I guess Vuetify can only be used with vue.js. Not sure if stack decisions should be driven by a UI framework though ahah.

I can do a proper analysis spike on different frameworks for us to assess them properly, if needed.

For the front shop website, I am not entirely sure. Thinking out lout, I’m a bit worried that adopting a framework might limit the potential to explore ways of designing the most appropriate interface for the final users, and result in just a bunch of components assembled together, and less of a cohesive experience.
But I’m not too familiar with it, Yuko is definitely the best person to provide inputs to that.

One question I have is internationalization, alphabets support and overall accessibility and inclusion. As OFN grows, hopefully we’ll be able to support a even more diverse range of people, with different needs, languages and ways of using technology, so finding a framework that has good foundations for that might be relevant.