U and I need to talk

John,

As quick thoughts I want to mention that dashboard is just a visual expression of a bigger image, it is what is called Business inteligence and I think we should take ideas also from those applications (I may be wrong but that is how I understand it). I will try to bring some later.

Also the budet and cash flow are oportunity areas we should review.

Alfredo

Well, John you should get lots of feedback in this area as I beleive this is a subject on which everybody has got and idea. In keeping with the stage of this discussion I would like to add some broad, general comments to get things started. First of all you have already mentioned some excellent point in your post on this subject in the issues forum.

I believe the phrase "easy to use" is the most over used pharse in our business. It has just never made sense to me. Anything a person knows how to do is easy to that person, but could be very difficult for someone who doesn't know. I remember years ago looking at DOS application created by a very expeienced developer who had substantial user base that was very happy. He just was convinced it was "easy to use". When I first looked I thought "how in the world does this work?". I did not know how to use it so to me it was very hard. Summed up then if you know how to do something it is easy and if you don't know how it is hard.

I think a much better phrase is "easy to learn". Today, as most users know a button clcik will probably perform some action, an action that is usually spelled out on the button face,etc, etc. My observation is that for an application to be "easy to learn" requires consistency more than anything. Consistency in screen appearance, button locations, etc., but perhaps even more important is menu construction. For example if Accounts Receiveable is organized by say Transaction, Reports, Setup, then Accounts Payable should be Transactions, Reports, Setup. My observation is that users spend more time hunting for where to start a specific screen than how to use it once it is open. Consistentcy in menu organization helps that a lot. I would very much like this community to consider adopting the phrase "easy to learn" as our mantra.

In your earlier post you had mentioned combining lists and searches to get rid of redundacy and that would certainly be a good thing and would help in menu organization.

I think the "Workbench" that Carolyn wrote about recently using the Customer Workbench as an example is an excellent presentation and searching mechanism. We have other "Workbenches", but I believe are setting a good standard with the Customer Workbench and I would guess that your alreay planning to expand and perfect that idea and I would further guess that the community would be in agreement with that concept.

I would like to close with one specific general suggestion and that concerns verbage. Since a lot of what we do creates general ledger transactions and the word "post" has long had the connotation of creating transactions, I would like to see the word "post" used only to describe an action that will create a ledger transaction and to be consitent the word "post" is always used to describe an action that will create aledger transaction. Example, for example I don't like "post a purchase order" because there are no ledger transactions created.Perhaps "release", "approve", "finalize", whatever, but not "post".

Perhaps that is a little nit picky but being totally consistent does require being a little nit picky.

Like John said, lets hear from everyone on this subject.

Larry makes a good point on the strained use of the verb "to post"... anyone want to make a list of places we need to fix?

I have noticed that most users only need a very small sub set of the menus presented. As a result if each menu remembered which items were regularly used and display them whilst hiding others this would help speed up menu operations. Then having a show all button for the complete menu would get users started. This would allow Users to quickly return to there favourite screens.

Another possible menu created by the users actions could be recent user items (similar) to the windows approach.

Menu and Icon customisation have been mentioned before and having the ability to save and restore these built in would be useful.

Maybe a menu search would also be useful for new users with a cross reference of usual business and accounting terminologies. For instance Inventory = Stock, Item = components.

Have the menus automatically show the custom function keys next to them would be helpful. So as with word or excel when a custom function key is selected the menu item becomes "itemsite (F4)". Allow global function key groups to be set up so that departments can all have the same function key setting quickly.

These are a few ideas which hope are of use.

Just a few comments for now:

*Please* don't hide menu items. This goes all the way back to the very first Mac Human Interface Guidelines--hiding makes it almost impossible to discover what can be done. Modality is generally a bad thing, and changing the menus according to user or document status (other than greying out what can't be used) is highly modal. I could maybe get behind allowing the user or the administrator to customize the menu layout, but the application should not do so on its own.

The entire application could use more consistency between windows. In some windows, cmd-W works to close the window and in some it doesn't; in some windows esc clicks the cancel button and in some it doesn't; in some windows enter or return clicks the blue button and in some it doesn't. It's quite frustrating to use an application that obviously can conform to interface guidelines, but doesn't. Even more so, the Inventory History window is often wider than my 24" screen, which is kind of ridiculous--the check for screen size is just not being done before it is scaled.

I do agree that some reorg of the menus is worthwhile, and I definitely agree that the word Post should be only for GL.

I would be very happy if the right-click menus were consistent from screen to screen.

The manual would be vastly better with some explanation of what things like Class Code and Product Category are meant to be used for--we made some decisions during implementation that I would certainly have made differently now, having figured out the meaning of xTuple terms by trial and error and lots of poking around with pgAdmin.

Thanks for listening!

Nelson

In the last post I mentioned menu hiding. This may have been the wrong way to describe the type of adaptable menu our users would benefit from.

In packages such as word you can always view all menus items available at any point, as within each menu such as "file" there is an expand button at the bottom. The Expand button shows all available even if they are disabled.

Our users are always complain that the spend most of there time looking around the menus trying to find things they have used before. If the menus were reduced to items used frequently they would not spend as much time looking through them.

However as there are lots of different ways of working, if for any reason this feature was not required by a user, there could be a preference to turn it off. Also a manual override to the sub set could be another preference, turning off the auto feature.

The other idea was to have a common menu of recently used items which could also be a user preference. This could be in a indented type structure or a single level.

I like the idea of begin able to look at the menus as work flow, so maybe we could have an option to should workflow menus or departmental menus to cover everyone.

In my particular case I don't like the idea of removing redundant menu access because the option of enter a screen from different menus give the person in charge of assign priviledges the posibility to give a user acess to what he need without activating another full menu; for example, if you remove billing selection from the sales menu you will need to activate the entire Accounting menu in order to let the user to get there and that way you end activating almost the full menu to all the users.
In my case I like the use of ribbon interface like office 2007, let me access very quick any option from a huge menu of option and also let me create custom toolbar; that way I can acess everything very fast. Of course I don't know if this kind of interfacehas been implemented in Qt.
I fully support the idea or leave the word POST just for G/L transactions.
When everyone talk about menus as work flow, I am not quite sure what it means, I remember testing compiere and adampiere and the menu is that way, I think it is too hard to use when the work flow is split in different persons and each one make a part of the process because then the user in the middle is lost trying to find where is his part of the menu.

Regards.

Alfredo

good project only needs to enhance user interface , modernize the looks and feel of the project , and the most needed thing is to replace detail records in every screen with a grid control , u know like voucher or sales bill , when it comes to items it is preferred to have grid control , users understands detail records more when they find it editable grid control , the user interface needs also enhancements towards modern styles like office or outlook may be thats hard but it is worth , hmmm also on-line help and , context sensitive help , and documentation inside the application makes application more user oriented , thats some ideas , and don't go to web now , still 90-95% of the user prefer the client-server model , still web is not the most granted choice enough to handle real business , i think u should not move to web before 2012 , also why not to mix the free modules in Xchange to the original application as long as it is free , hmmmm i hope that i said something that other users will support me in this ideas , thanks for ur great work

1. Consistent Keyboard Controls - This is the #1 thing IMO. There are still very many users who are keyboard centric (perhaps a majority), and are never going to become mouse people.
2. Data Driven menus that allow arrangement and hiding according to some schema (permission groups, for instance).
2a. The option to create a 'custom' menu tailored to individual users or groups, so that they only see that specific menu list.
3. If #2 is not an option, then the menu needs to be consistent and logical. Presently it seems chaotic.
4. I agree with icartee and jrogelstad that words mean things and consitant verbage is important.

Shane

Here's my thoughts. For reference, I'm a fairly new user on version 3.2.2 coming most recently from Quickbooks, but with experience in QB, JAMIS and Deltek Costpoint.

Navigating Screens-
-Screens should always open with a default control selected that is the most likely item you'll use (textbox on Search screens, etc.)
-Consistent labels on controls
-Logical tab order between controls
-Right clicking on objects in a list should give you the option to run reports or open other screens. For example, this works very well in the Customer Workbench, but not as well in most other screens (example right click on the list of open AR in the Cash Receipts screen and all you get is the export option).
-Pressing enter or return when you have selected a button by tab should result in pressing the button

Menus-
-Easy customization and ability to hide menu items from users. For a very basic user, its pretty cluttered up. I see that comment above, and John's comments seem to make sense (as do his comments about the right-click menus).
-More customization of the available buttons. It'd be nice if the users could create their own the same way they can create their own hotkeys.

As far as prettying things up, I'd be more interested in performance. So if you can use more interesting buttons/screens/grid controls, GREAT, but don't slow down the user experience to do it. And don't focus on that if its going to pull away from improving usability.

I'd really suggest you run a few "focus groups" with REAL USERS. When I come back to a site after a few months after go live, I'm always amazed at the things that real users do - they click stuff, open close screens / navigate in ways that were never intended or maybe even designed to be done.

The biggest suggestion I get from users is the abilty to put custom icon / menu buttons on the tool bar, and let the USER decide what action to take - very much like the hot-key assignment idea.

Also, get different age / experience levels. I for example, being ancient and set in my ways, love spartan menu systems. Younger users, raised on video games and iPods etc. have a very different visual experience - and you have to accommodate them both.

When I started using Open a few years ago, I really hated the interface - especially the old I/M, P/D etc. style menus. But when I learned my way around, it grew on me -- same thing with the "new" menus - so no I'm going to sound like Carolyn - who moved my menus!

But really - when the real users can show you how their lives are affected by the system, you'll get a better product.

The following comments are from a guy I know who is an expert on user interfaces and technical support, who gave me the go-ahead to post them here:

----------------------

Document Processing.
All my comments are related to this, as I said other less frequenty used data entry screens are adequate.
This applies to ALL document type in the system, as you know they all follow the same protocol.
It also applies to most document conversion processes etc.

Selecting Accounts/Products
You can only do this as either the full account/product code or otherwise select the full list. Would prefer if you could do a partial code entry or description and the select list function or whatever. Its too general.

Document Lines
You have to go to LINES followed by NEW, whereas the former should suffice by default.
The LINE input screen does not seem to have any travel mechanism except for mouse. You have to move mouse around and click into 'qty', 'price' and 'due date' seperately whch is a pain in the arse, the latter anyway should probably default to a todays date or something for these who do not use it. (Now this may ne settable in the parameter files, i havent checked just yet).
When you have the above entries there it will accept a 'return' to complete the line, but again you have to select NEW again if you want a 2nd line. It should go to the 2nd line entry screen by default in my opinion, and then you can esc or close that when not needed.

When you view/edit/delete/convert etc documents, it shows just the header info record. Should preferebly also show the line items without having to click on LINE button. And if you want to add lines to a document in edit mode, it should go to next blank line and position under the 'code' heading, rather than having to select NEW.

Quick Entry
There is a 'quick entry' option in the Purchase Order system, which should be globalized in modified format in in documents.
First pain with this, is that you must know the exact product code as there is no list function! Need this added.
You can travel across with arrow keys in this entry, but the 'return' key after an entry simply processes this, but does not travel to next column, hence an extra entry operation required unnecessarly. If its deemed a 'quick ' entry, it should probably move automatically from code, to qty to price to finish line with return keys only!
You also have to click on NEW line again after you SAVE previous one, which isnt exactly a quick process. It should go to next line by default after SAVE.

Another improvement to the user interface would be the addition of Trending, Pie Charts and other graphically represented data to some relevant reports.

It not something I have seen in business system, manly because the ones I have worked with are unix based text interface types.

Graphing is available with OpenRPT reports which is good. However within the application a small overview trend on some reports with the ability to zoom/open a detailed trend screen would be useful.

An example use would be on an inventory history report or a general ledger transaction report which shows change over time. The low detail x-y plot or trend could show date against value with min-max of the scale to give the operate a quick overview. Then when the detail screen was opened pointing at part of the graph could give the x-y values with a right click option to run a search/report/view based on them. I think this kind of interactive graph leads the operator quickly to the data they require.

Yeah that's right on. We've thought what might be best and most flexible is to simply create a handful of instrumentation widgets such as graph, spark line, bullet chart, on/off etc. that can be dragged on to windows in the graphical designer and driven by a metasql property. Of course being built that way they can be further manipulated with Script. Then you can basically put them anywhere and make them do anything you want. Pre-configured examples could be distributed as packages on the xChange. You like?

My favorite guideline on this topic is a book by Stephen Few called "Information Dashboard Design." (http://oreilly.com/catalog/9780596100162/). This book analyzes in depth what it takes to make dashboards effective, and in particular rips apart dozens of existing dashboard systems and shows why they are not. I think this is a wonderfully exciting opportunity to design a dashboard paradigm built into a full ERP system that actually works. It's actually great that we don't have it yet, because we the luxury of hindsight to look at all the mistakes others have made and learn from that when we move forward to make sure we get it right.

Having widgets which can be apply to any reports sounds like a great idea.

> What do you absolutely not want us to change?

(1) Please do not remove the traditional static (everything visible, non-context sensitive) text menus, ever! These are very useful compared to icons when directing users to specific functionality or when browsing for specific functionality. I actually think the current menu structure is good.

> In particular, we are looking for feedback on general organization such as navigation, search capabilities, and data organization.

(1) Screen to screen navigation: Suggest adding a quick optional way to get to a specific screen. Another ERP package we use offers a navigation box in which the user can type a screen code and go immediately to that screen.

This is more efficient than clicking through the menu and more efficient than having to reach for the mouse to click an icon.

This is similar in concept to the Hotkeys but would be standard for all users which facilitates communication, training and company documentation of procedures.

Since most users need less than 10 screens the needed codes are quickly memorized.

For example to go to: Accounting > Reports > G/L Transactions
The key sequence might be: Esc > GLTG > Return

I would suggest that the navigation box be placed to the right of the text menu. Screen codes could be included in the text menus and/or screen title bars. This feature set could be displayed or not as a user preference.

If all the above is too much maybe just allow a custom text menu like on OpenOffice.

(2) Intra-screen navigation: Optimize the tab order on all screens typically used for data input (See Series G/L Journal Entry screen for example of awkward tab order). In most cases having to use the mouse to complete a data entry task reduces efficiency. I also agree with nclaytor's comments with respect to intra-screen navigation.

(3) Data organization: Various screens such as the BOM screen use colors to indicate additional information. This is quite useful but it would be nice if the screen also included a short field with the same information (BOMs: M for Manufactured; P for Purchased; etc.) for the case where the data is exported or Printed to a non-color printer.

Keep up the great work on xTuple!

Continuation of above thoughts .... besides a better alternative to Hot Keys like the "Navigation Box" suggested above the regular text menu could be improved as follows:

Add "Products > BOM > Search. There is a "Products > Item > Search" but no equivalent for BOMs.

Add a way to go directly to the "Item" screen and "Bill of Materials" screen:
Products > Item > Item
Products > Bill of Materials > BOM

For these screens the Item field must allow input of the part number and use of Ctrl+A, Ctrl+S, Ctrl+L. AND, the user should be able to view another/different Item or BOM simply by entering the Item number in that same field (without closing the screen).

Ironically, xTuple is a products based software package yet requires multiple steps to see Item and BOM data. For a company with thousands of Items and BOMs like where I work all these extra navigation steps waste time and become quite annoying to the users.

I'm a fan of the current menu structures and screens, and I particularly like the ease in which you can link between screens using some of the buttons. The interface needs to be clean, modern and understandable. It should be obvious what the next step you need to take is without having to refer constantly to a manual.

Good design should be easy to understand and intuitive for most users. The best example I can think of is the iPhone which does not come with a user manual - it doesn't need one!.

One idea is a guided workflow. Take a standard process such as Purchasing and have a screen that steps you through the process -> Raise a PO -> Post PO -> Receipt PO -> Close PO. This could allow any user to process a PO without the need for training.

Hi, I am very new to xTuple so I can't offer much yet.

I think it would help to have the icon buttons represented in the help files next to the relevant titles. Shouldn't be difficult to do and it would help idiot people like me go thru the learning process.

Thanks,
Creighton.

Hi, Creighton:

Is this what you're looking for? Or are you thinking of something different?

http://www.xtuple.org/sites/default/files/refguide/RefGuide-3.4/pr01s02....

Regards,
Pierce

For those of you following this thread who had interest in keyboard navigation issues, you may be interested in my latest blog:
http://www.xtuple.org/node/2731

When wanting to look up an order in xTuple there is generally an option to go to a list of orders, a workbench (through the CRM of the order) or through various screens that are specific to a menu (i.e. PO Items by Date).

The user wants to type in the document number and see it, not navigate through screens, clicking their way to find it. Each module (Item, Inventory, Sales, Accounting, Purchase) needs a screen to simply type in a document number and view the information and then be able to do any editing to it based on privileges, not go somewhere else to maintain it, but do it there, all in one place. I.e. to adjust receiving in a PO you should be able to do it in the PO itself.

Just a general UI comment. Any where that an item code is available, the description should be available as well. For example, when working in the Inventory History by Class Code report, I find my self often having to go back and forth between that and another screen just to look up a product description from its code (Description isn't available in the data).