wow… that’s really really cool man… love it and looking forward to use it…
To all the devs who know frappe backwards and forwards, is that an easy ask? If we rearrange that many files is it an easy switch between the two?
I’ve been looking at how the modules config files are setup and it seems easy to rearrange but not sure about how to flip back and forth. If anyone had a clear path on how they would go about it, speak up and we can get started if the option is critical to most.
I added the container thing in my theme a while back. Huge plus. Love it.
Hi @joshreeder
This looks very good! 
I agree with folks that say there should be a toggle between this and the tradittional desktop. More importantly, I’d like to know what would be the default view for users when they login? There are a couple of threads on the forum where UI issues were discussed and the idea of having some sort of widgetized landing page with configurable dashboards seems to be fairly popular
With Navigation Icons being moved to the sidebar in this new design, I would think it should be a good opportunity to look into the issue of having configurable dashboards/widgets on the landing page (Desk)
Kind regards,
1 Like
Even if this achievable easily at the beginning, it will become a nightmare for developers to maintain consistency and updates for the two different UI. Also the platform will start having identity crisis with different interfaces lol.
So the right way of doing interface revamp is to slowly introduce changes between updates so the end use get familiar and not get shocked, and the end result is the users transition to new UI without much complaints.
5 Likes
Makes sense!
Great work and initiative!
I just hope that the module access menu on the left is accessible so that I wont have to scroll down to click on a module
I am working on this too. I’ll finish it up and share. For the first pass, see the menu builder. The module icon has the option to set the path for initial path for selecting a module and I will add a default module choice for the site home page but want to add dashboard builder that can be used for these and som defaults.
Not sure I follow. You mean the traditional modules view? My goal is that that is reorganized into a admin settings set of items and normal app use for everyday records is part of the new organization. This makes both things far less huge. Now that admin settings and setup (traditional modules view) is accessible if you have privledges in the top user nav dropdown in your user name. So for admins it’s even easier to access.
Also if you are an admin, and you are using the settings view from the top, and say the menu selection is developer/doctypes and you edit one and then accesss it from the sidebar to test and then go back to the doctype menu. The paths are still set since they are different menus now and they will default to were you last were thanks to how they are appended and hidden as you go through the system. A huge benefit and mentally satisfying to be able to build and then use. One from the top menu and one from the side. Separating these roles will help the developer see through the eyes of the user they are trying to serve well.
I have tried to do that oddly enough. Not sure there is a half way for reorganizing menus. When google updates there ui they allow users to upgrade or not and try to support the old for a while.
How does that feel? If we can get this done on a branch, and we like it we offer 2 builds for a while after making this one a major release but also offer the other for a long time it just won’t see all of the following upgrades.
Does that sound like the right direction?
2 Likes
Some thoughts
- Simplify the list of menus on the left side. There isn’t really a need to use the rounded square design anymore in that context. Just retain the octicon/fontawesome icon and the module name. Thats what most other apps do these days.
- The “selected module non-child doctypes” section won’t scale. Looking at the accounts module right now, there are 30+ links - where are those supposed to go in this new proposed navigation? I see the ideas of lumping things into reports and so on, but that also has limited scalability.
- In my opinion, a viable proposed first cut of this would be the following
A. Remove the “desk” - that’s basically a glorified list of links/bookmarks honestly.
B. Module navigation takes place using a bar on the left side, as proposed in the mockups
C. Add a Viewport to take advantage of higher-res monitors (Fill screen width to show more columns, and more discussions in the forum) - in the initial release, make this possible, but each module would retain the current “2 column” view until they can be reworked.
D. Modify slickgrid or the new FrappeGrid component to be full-screen in the new viewport
E. Keep everything else the same for now. Iteratively work on wider module viewports until that task is complete.
3 Likes
Great thoughts. I see your point but have considered this extensively and parsed through every single non child doctype. Around 300. I’d does scale if you consider what doctypes are used by the user everyday (about 50) and what doctypes are used inside those (contacts/addresses or product groups or bundles) and are not needed in menus or can be easily added as a button to the appropriate body section head ( in the items list add button for groups and bundles) or used for setup reasons and moved to the settings menu (customers / customer groups).
This means that list is way smaller.
In my opinion, we can do this and everyone will love it once they have lived with it for a week.
Some of us need to think as developers and others as user advocates.
Nothing is going away, this is a simple idea. Reorganize the doctypes by adding a new category selection:
Document (Master)
Sub document (supporting document)
Setup (top nav menu: Settings / Modules: Setup)
Settings (top nav menu: Settings / Modules: Setup
This is how all great systems work and are organized and we need to get there. We can do it iteratively or we can just get it done.
I think we use the momentum to get it done.
It’ll take a few days to show where all 300 doctypes and other pages views would live but charge out the view above with the settings called out and look at the organization. I think your gonna love it.
1 Like
I posted 1. It shows the side bar with both the modules and menu visible. Don’t have it fully designed but the gist is tap a icon and then tap the submenu item to dismiss the menu.
Hi @joshreeder
Point 1 is what I was trying to say. Users would not want to scroll down to access a menu.
I completely agree and that’s why I am working on this. Right now there is no distinction from desktop what is going to dump you into the massive scrolling modules view with no memorable organization or a list view. Colors and icons and names are all on the same level.
Not sure which user you are referring to. Are you referring to the dev/admin or the everyday user of the system?
For the dev all settings are accessed from the top nav. No scrolling. It’s a page that is 1/3 of the current modules list and page length so no scrolling.
For the user, most will never scroll. They will be given 5-12 module icons they can rearrange the most common to the top. Icons can get smaller and no tile outline. Names can be just tooltips. No scrolling. And the sub menus have there documents at the top. No scrolling.
So I definitely agree and that is the point of this whole project.
2 Likes
Updated View showing no tile icons with a rollover state and the dom changes that fix layout to Bootstrap grid properly.
Names via right tooltip not working yet.
http://www.giphy.com/gifs/xT9IgCDe07de1YthsY
That looks really pixelated… look at this for full screen…
3 Likes
Cool designs. I’d like to share my thoughts:
- Breadcrumbs are crucial to navigate any UI. I think they have been validated as good UX.
- In earlier versions of ERPNext, icons were heavily used. But we went for text as they are easy to understand.
- The side navigation is cool but the desk is an iconic part of frappé. If there is no desk to go back to, it may feel weird
Maybe we can start by implementing a small feature from these, and do progressive enhancements, rather than doing it in one big PR.
7 Likes
I’m personally not a fan of burying functionality like this. ERPNext is so powerful that discoverability is an issue - I often find new features by scrolling through links. And I don’t see how you can do this in a complex module like the Accounts Module, as an example.
However, I do get your point - feature the most used links and bury the rest. That’s just good UX in general. I’ll wait to see what you come up with.
Maybe a compromise would be to bury things, but have a flyout menu of some kind a user can click on to show everything in the module, as is currently possible. But that seems like a cheesy compromise…
Iconic, yes. Functional…not really…it adds a click to move between modules. Yes its just one click, but I hate that click so much 
5 Likes