Experimental inteface

[timschofield]

For a long time, I have kept private branches where I play around with very experimental inteface designs that never see the light of day. I would however like to broaden out the discussion on interfaces. I have pushed my latest attempt at a new interface to a "prototype-new-interface" branch on github, and created a https://weberp.org/experimental/ site where people can see it in action. After the login, the "hamburger icon" in the top left takes you into the menu system. This site will regularly update as I add stuff to that branch.

This isn't a "this is how Tim says webERP is going to look" branch, it is more of a "here are some ideas Tim has created by letting his imagination go a bit" branch.

As always, constructive criticism is welcomed. Remember, I have always said that as a designer I make a very good accountant :-)

Tim

[dalers]

Very interesting....

I haven't done more than kick one of the tires but will say the familiarity of the hamburger menu may help the new user experience, in particular those who primarily use mobile devices. Iiuc, the "hamburger" menu was created to preserve screen space on mobile devices but it doens't seem particuilarly needed for webERP (except perhaps when using a mobile device).

Did you have functional goals or requirements for a new UI/UX? Was the purpose only to explore a different type of UI to see where it led?

That being said, I still prefer the current UI because it requires less clicks to access a particular module menu entry and all the module menu items are visible at the same time instead of having to access the module menu panels individually (I often don't know in advance which panel will have the menu entry I'm looking for). I also found the use of cascading pop-up windows more intrusive than useful, especially duplicating the menu system in a popup window (screenshot). Is the purpose to have multiple windows open simultaneously?

However, I readily admit I've spent less than 5 minutes using the experimental interface and these observations are likely more emotional than rationale.

[dalers]

I like the existing menu system because it shows more menu with less clicks. Once a module menu item has been selected the UI is the responsibility of the linked script and the menu is irrelevent until the script is done with. I find the existing menu user experience works well enough on a smaller mobile screen with the panels presented vertically instead of horizontally - just more vertical scrolling to find a desired menu item.

I think my use aligns with a new or occassional user, who is essentially finding their way new each time and seeing more of the menu without having to click around is a huge advantage. However, I can also envision an advanced user who remembers the path to their most used menu items and would appreciate on a small screen being able to navigate the menu with less scrolling (albeit more tapping). To be sure, this is only on a small screen, I don't see a issue with the existing menu system on a larger PC monitor.

One could also argue though that a user should simply add their favorite half-dozen scripts to their Favorites.

[pakricard]

Hi Tim:

Thanks for sharing this. I've been also playing 5 minutes with it. Seems OK, and I agree that current webERP looks outdated.

I'm in favour of tabbed windows to get rid of the 3 column restriction, to better organize options. Moreover, the list of modules can grow without taking always a bit portion of main page real estate.

Allowing multiple instances of the same menu in webERP: What is really the goal? What can't be achieved with any modern browser (all have tabs) that should be achieved inside webERP?

Having multiple windows of similar scripts leads to bugs, in my experience. As an example: an user who processes PO's and have 2 or more PO's opened in different tabs, ends up with mixed data. I never found the workaround, except by recommending (forbidding) users to use multiple tabs on the same subject. I guess this is due on how we use global variables, identifiers, etc. Fixing this would need "wholesale changes" in the scripts, I believe.

Related with the Font Selector: Do we really need this? webERP is always executed in a browser. Browsers take perfectly care of zoom. What is the goal of the font size selector inside webERP?

Also: Theme selector: Should it be better located inside the user settings script?

My point is, a cleaner, simpler page makes work easier. webERP is not a "fun website" or a "selling website" but a working place. If we help to keep the users focused with fewer distractions on the screen, wouldn't it be better?

It's a bit las the "outdated look". Yes, we agree it looks outdated, but no company will choose an ERP A because it looks better than ERP B, even if functionalities are worst. Winner is teh ERP with more, better, flexible functionalities. This is the strong point of webERP, not the looks ;-)

R

[timschofield]

@pakricard and @dalers, I agree that functionality is a major driver of takeup of takeup of webERP and I am working hard to fill the gaps in our functionality.
However I do also think a professional and modern looking interface helps to give the impression we are a professional and modern project. I don't for one minute think my JS and CSS ramblings constiute a professional and modern look. I am simply trying to spark debate. What we need is someone way better than me to try and reimagine the interface

[dalers]

Having multiple windows of similar scripts leads to bugs, in my experience. ... I guess this is due on how we use global variables, identifiers, etc.

That's interesting. Good to know....

Font Selector: Do we really need this? webERP is always executed in a browser. Browsers take perfectly care of zoom. What is the goal of the font size selector inside webERP?

I've been thinking of the difference between having direct buttons and a variable in my user config. I was going to recommend keeping the size buttons because they seem a useful shortcut, but maybe not. Fwiw, I mostly use a wide-screen PC monitor or laptop and leave the size set to High.

However I do also think a professional and modern looking interface helps to give the impression we are a professional and modern project.

True, to people looking for "a professional and modern looking interface". Others will look at the development and control aspect of the webERP project to guage how professional it is, others will only want to know how it makes their lives easier (including the person who has to train someone new). That being said, sometimes a change is needed for changes sake just to be noticed.

What we need is someone way better than me to try and reimagine the interface

Easier said than done ;-)

Who would be "way better"? A more senior or experienced accountant? A financial analysist? A manufacturing supervisor? A javascript web app developer? A User Experience expert?

You iiuc are the only person active here who has implemented webERP for more than one company and you may very well already be the best there is in one person. The module-based 3-pane menu interface also may already be the best there is (although I need to say here I do like the idea of a hotkey in the corner that I can use ot tap through a path to the script of interest).

However, everyone's better at some things than others, and you have to be plugged into an industry to know where it's going and what it needs. I watch MS Dynamics, NetSuite, SalesForce, Epicor, Odoo, Tryton and NextERP (frappe) to be aware of what features they offer, their user interface, how I would do what I do, and how much they cost. However, what they are doing exactly is not as directly relevent to webERP as the market intelligence it provides about users and their problems, and where the other business management software is a poor fit.

There's value in staying simple and focus on the original webERP mission statements. Attempting too much is an easy way to fail and at the very least is a diversion of efforts. There's value in staying simple and simpleness is a strength becuase it makes all other things simpler.

I would say webERP should focus on the basics of solving the problems of a non-typical small business with rigour above all else. No auditor in the world should be able to find fault with amounts, traceabiltiy and control when a system is configured correctly according to published documentation. "Typical" customers are QuickBooks customers and webERP shouldn't try to be all things to all people or it will be something but to no one. In hindsight, enterprises succeed when they have a passion to be the best at something and stick with it - the customers eventually followed or their absence showed when something else was important. Imho, there is room in market for webERP as well as both commercial and open source competitors if webERP can carve out a place for itself that is special compared to the others.

Have you thought about offering an internship at your local tech or programming school? A suitable 2nd-year or 4th-year project (depending on the school) could range from:

• e.g. simple, develop some proof-of-concept JS/CSS systems, or
• e.g. complicated, use the latest technology hostness at the school is to build a complete app using the webERP API.

Without having to change webERP in the slightest, one could start with a blank slate and create a stand-alone "modern" app using current "best practices" for user interface and experience and latest technologies. I seem recall a community member is already on this path, having contributed API extensions so that their user app could do everything it needed to (with no need afterwards for the "standard" webERP interface and webERP would effectively be used "headless").

You could also look approach a financial college for e.g. a business process student, or possibly a computer geek who happens to like the financial world. There could possibly be a kick-starter or incubator project, or there could be government funding available (unfortunately at least here it requires one to be incorporporated, which I'm not).

[timschofield]

True, to the person looking for "a professional and modern looking interface". Some will focus on the development and control aspect of the webERP project to determine how professional it is and others will only want to know how it makes their live easier (including the person who has to train someone new). That being said, sometimes a change is needed for a changes sake.

A poor quality interface says "the developers of this software don't take good care of what they produce". A professional and modern interface says "the developers of this software are professional and modern". This is especially true in the FOSS world, as potential users are already sceptical about whether they can trust something that is "free"

Have you thought about offering an internship at your local tech or programming school? A suitable 2nd-year or 4th-year project (depending on the school) could range from:

* e.g. simple, develop some proof-of-concept JS/CSS systems, or

* e.g. complicated, use the latest technology hostness at the school is to build a complete app using the webERP API.

Without having to change webERP in the slightest, one could start with a blank slate and create a stand-alone "modern" app using current "best practices" for user interface and experience and latest technologies. I seem recall a community member is already on this path, having contributed API extensions so that their user app could do everything it needed to (with no need afterwards for the "standard" webERP interface and webERP would effectively be used "headless").

You could also look approach a financial college for e.g. a business process student, or possibly a computer geek who happens to like the financial world. There could possibly be a kick-starter or incubator project, or there could be government funding available (unfortunately at least here it requires one to be incorporporated, which I'm not).

Once upon a time I led a project at Makerere University in Kampala with a group of students working on webERP. I won't go into details (the wounds are still too fresh :-) ) but it turns out, that some people may be good at that sort of thing, however I am not one of them.

[timschofield]

All the major ERP vendors have changed their user interfaces over the years. However ERPs tend to be conservative in nature, and changes are evolutionary rather than revolutionary. They have constantly been polished and made to look more professional and modern while not changing the basic way they work. That was the general principle behind what I was doing with the experimental branch.

[dalers]

It occured to me that "for most users most of the time" scripts might be getting accessed from the user's Favorites. If this is true, perhaps Favorites should have a more dominant presence in the UI (or perhaps the current menu system could be de-emphasised e.g. under a "Full Menu" button a la the current Favorites button).

What do we know about the "common user" and their Favorites? Do the majority of users, once familiar with using webERP, use their Favorites most of the time and use the module/category menu system only occassionally or almost never?

If a Favorites-based system is the way to go, do you think users would want a way to order or sort entries, change the name of the favorite or organize favorites in groups by adding blank lines between ordered favorites or organized hierarchially by letting users create their own folders for their favorites?

I'm also posting this thought in the "Status of Menu Editor" discussion #756 because if anyone else also thinks this concept is worth pursuing it might affect the menu editor that tim is working on.

[timschofield]

I had an idea at what time to make this "Favourites" functionality more intelligent. By tracking a users workflow it could suggest better alternatives. For instance if a user mostly selects BankReconciliation.php on a Monday morning, then that would appear top of their favourites list on a Monday morning, gradually dropping down the list after.

It remained just an idea.

Tim

[dalers]

It remained just an idea.

Still a good idea though :-)

I had a similar idea but without the automation. Track user workflow (aka "script history") as you suggested and enable the user to manually add a script from their history to their favorites.

However, our ideas are compatible. The user Favorites button could open a child window (like the user manual opens in a child window) which could show both the user's manually crafted favorites list (tree?), and also their script history with an "order by" button to order in "reverse chronological" or by "frequency of use".