I'm developing a Winforms application which has been running for years with an explorer view (TreeView left, screen right). I means that:
All the screens have an hierarchy organization
All the nodes on TreeView have one and only one screen related.
A screen gets activated when a node on treeview gets selected.
One of the advantages is that the user has an ordered stucture and one of the inconveniencies is that with hundreds of screens the user gets confused.
I see other options: use classical menus, use tabs or a mix of everything.
Any advice for a good way to show a lot of screens to user in a user-friendly way?
Update: I'm changed "hundreds screens" by "a lot of screens". The most important thing is not show all at time but that the user can find what they need easily.
Update2: In this proposal, the user only see one screen at time.
Update3: I'm talking about handling multiple screens not showing multiple screens. No MDI, only one ontime.
I have used other applications similar to this is the past, and the major problem is trying to find the exact screen you want. There are two common solutions to this problem, shortcut codes and favorites menu.
With the shortcut codes, allocate a short code (5 or 6 characters) to each screen. The user then inputs this shortcut code into a text box which will then jump to the correct screen. Users will create their own list of often used codes.
For the favorites menu, allow users the ability to be able to create their own menu list in the structure they want. They will find things easier, if they organize it themselves.
Why do you need to show so many seprate screens at once? Why not just show the screen for the currnetly selected node, why are all needed at once?
If it is all tabular data is is probably too much to be consumed all at once, if it is graphical data, could it not be combined?
There may be a valid reason to show all the data at once or there may not, hard to tell from what is provided in your question. With that said, better to keep it simple than overload the user. MDI apps are never easy to use.
Tabs may work for a small set of items but still is not a good UI for hundreds of items.
If you are only showing one element at a time, out of hundreds possible on the tree nodes, then that is fine. The one screen showing at a time would be contextual to the item selected as the user moves through the nodes. Think of the Outlook approach where what is selected in the left pane is displayed in the right pane in whatever form fits the data being displayed.
Have you considered the Office Ribbon?
The Ribbon gives you a lot of flexibility on how to show and
organize functions and it's highly visual.
Here is a good link about the Ribbon and also here
To use the Ribbon you have to license it from Microsoft. You can do that online.
Providing the user with ketboard shotcuts is usually a good thing too.
I also like to provide the user with an "autocomplete" field on the menu
so that they can can find the function by name (or part of it) and be
able to navigate directly to where they want to go.
I general I find trees to be a bad idea, especially if your "hierarchy" is of a small fixed depth.
If you have a small fixed depth, consider replacing the tree with a list. At the top of the list can be drop-downs for filtering based on the node-level properties. It will use up less screen real-estate because it is vertical-only, with no horizontal component.
Clicking on an item can display it in the view (like currently), but it may be a good idea to allow a user to double-click on more than one item which could launch more windows, or tile with the existing displayed items. (I am assuming that currently, the user only sees a single detailed view at once in any given window.)
Actually, it’s hard to beat a hierarchy for organizing large numbers of items. I wouldn’t favor a classical pulldown menu for vast numbers of windows because it would be even harder to keep track of where you are than in a tree (e.g., a tree lets you look in multiple branches at once). But here’s a few alternatives:
I’m not clear how you ended up with so many windows, but maybe it comes from combinations of classes, views, content, and detail, or maybe it comes from using a task-centered UI structure for something far too complex (I’ve more on that at http://www.zuschlogin.com/?p=3). For complex apps, you want a different primary window for each significant class of data object (e.g., invoices, employees). These are listed on one menu, and typically there’s few enough (15 or less) that it can be single non-cascading pulldown menu. The content of each window is set by a separate menu, perhaps by a menu item that opens a dialog that may include a list box (like an Open dialog) or other controls for querying/searching. The “view” of each window (how the data objects are shown, e.g., table versus form) is set by menu items in the View menu. Details for any given object in a window can be shown in a separate pane within the window in a master-detail relation, essentially turning you data objects into a menu for details. A single window can have multiple detail panes for the user to open and close to select the specific detail to show. Tabs may also be used within a single pane to fit subdivisions of content.
You say it’s not important to show all window options at once, but often showing all options at once makes it easiest for users to find what they need. Maybe you need a “home” window that lists all the other windows in organized, labeled, and separated categories. This is will be easier to use than the tree if your users select a window then stick with it for most of the session. Your tree is better if there's frequently selection of windows throughout the session, owing to the overhead of getting to the home window. If all windows/options don’t fit on a single home window, then show only selected common windows for each category on the home window and provide a button or link to show an exhaustive list.
If you’re talking 100’s of windows, maybe you should have Search, perhaps in addition to a menu-based browse approach to getting to a window.
In any case, providing easy access to the few most commonly used windows is a good idea. Such windows can be explicitly selected by the designer, based on user research, or selected by the the user (favorites), but it also typically works well to make it automatic with an algorithm that uses some combination of frequency and recency of use.
Related
I've been building my Codename One app for the phone screen format so far. There is a separate Form for the main menu, then a second Form with a list of elements, and then a third Form to edit an element selected from the list. Each Form has an overflow menu and various Titlebar command buttons. And each (Extended) Form has a lot of code that implements the functions in the Form and shares variables etc.
However, to use the tablet (iPad) screen estate, I would like to show the main menu on the left of the screen, the list of elements in the middle and the element edit form on the right. Something similar to the screenshot below. This seems to be a common type of layout on tablets and suits my app usage pattern well.
However, I don't see an elegant way of structuring the code to do this. I can't easily combine the list and edit Forms into one Form, and writing a completely new Form just for the tablet format would be a lot of work. I assume others have faced the same challenge and would love to hear how you achieved this.
PS. I know the side menu can be made permanent but that only solves part of the problem, not how to show a list and edit Forms at the same time.
There is no one answer for this but if you look at apps like Codename One Build you would notice they adapt to this form factor.
We usually just use isTablet() to adapt the UI at key points to the different form factor. One element is the permanent side menu which we turn on in the init method using code like this:
if(Display.getInstance().isTablet()) {
Toolbar.setPermanentSideMenu(true);
}
It makes the side menu stay open all the time. Within the code we try to use Container instead of Form. This allows us to package multiple logical pieces into a single UI for the tablet mode.
What do people think about using pretend hyperlinks, in Winforms apps?
Example:
In my example you would click "into" the Organisation record card for Acme Corp Inc or "into" the details of the next appointment.
If we ignore, for the moment, how the user edits the Organisation or adds/removes an appointment, is it a sensible UI in Winforms to use blue & underline to signify click here and i'll take you to a new screen
As in:
TextBox1.Font = New Font("Blah", 8.25!, FontStyle.Underline etc
TextBox1.ForeColor = Color.Blue
Not forgetting:
TextBox1.Cursor = Cursors.Hand
This would be for a reasonably rich application (for example a CRM) where you have a lot of different kinds of screens and the user is navigating between all sorts of records. And you want to show the user that he can navigate between detail views, grids, children, parents, siblings etc.
Pros:
it's familiar to users and it's
obvious, without being obtrusive or
taking up any screen real estate
easy to implement
the often-used alternative (a button
with an icon or even just three dots
[...]) looks a bit old-fashioned,
doesn't work very well in grids, and
takes up space
Cons:
with all the flexibility and control
you have in a Winforms front end, you
should be able to devise a smart ui
without needing to borrow from
browsers (maybe???)
these pseudo links won't behave as
true anchor tags (there won't be any
"visited" [ie. turn me purple if I've
already been in here] or "hover"
behaviour and no open-in-new-tab
features, without a lot of work) ... potentially annoying to users?
detracts from genuine hyperlinks (as
in email addresses etc) - these no
longer stand out as links "out to
the internet" (to the browser, to
email client) ... very minor issue?
Not even browsers work this way. Use a LinkLabel, not a TextBox.
In general, it’s a good idea to use hyperlinks (real or simulated) in thick-client apps for opening forms of additional information. It is helpful to distinguish between a control that merely navigates (a hyperlink) and a command that changes the underlying data (a command button), so the users know what they’re getting into. I don't think most users care (or even know) if a browser is involved or not. Navigating is navigating.
Making an attribute value look and act like a hyperlink like you’ve done is fine except for one thing that is a showstopper for most applications: it precludes any other interaction with the attribute. The user can’t edit or even copy the attribute value since any clicking in the field will launch the new form. Keep in mind that to edit a value, such as to correct a day of the month, the user may be inclined to click in the middle of the field to position the cursor. Even if you’re using a drop-down menu (e.g., to set the organization), you want to allow users to click in the field and select by typing the first few letters of the value they want. If your app has one drill-down-able field that needs to be editable, then for internal consistency none of your fields can use hyperlinks –all drilldown needs to be by some other method.
Also, while hyperlinks are intuitive for navigating, such as drill-down, I’m not so sure they’re good for assigning a field value. There is a difference between getting more information about Acme Corp organization (which is what your Acme Corp link implies) and getting a dialog to pick the organization for John Smith (an assignment function). So if your intent is assignment rather than true drill-down, then links are probably not a good idea. For assignment, the button with the three dots makes a lot of sense. Assignment changes the underlying data, so it should use a command button. It’s a natural extension of the button in a dropdown control. The three-dot button caption minimizes the space used and is associated with dialogs since that’s what they imply in menu and button captions. It might look old-fashioned, but that’s why it works –it’s consistent with past user experiences.
Looks okay to me. The concept of links has anyway already migrated from web to desktop applications. Users should accept this without problems (maybe after first ten minutes playing out with your program).
Also quite popular in enterprise applications.
Maybe consider changing the color, to, maybe brown or green, so that it doesn't immediately imply a native web link.
Also many web applications built with some event-driven frameworks (like ASP.NET WebForms, JSF etc.) heavily use links that do not link anywhere but invoke some server-side processing (basically an event handler). So it's not unusual use.
I don't like it. If I see a link I expect it to open a browser window when clicked. More standard would be to have a little "edit" button/icon next the label. You could get away with having a link-style "(edit)" after the text, that would also look quite normal rather than suggesting a browser is involved.
e.g:
Organisation: | Acme Dustbins (edit) |or
Organisation: | Acme Dustbins| (edit)
In order to make a convenient UI for an .Net 2.0 Winforms application I am working on, I have need for a control that I'm pretty sure goes beyond the "out of the box" behavior of any standard control. A mock-up of what I'm trying to achieve follows:
Mock up http://www.claware.com/images/temp/mockup.png
Essentially, this part of the application attempts to parse words into syllables from tribal languages (no dictionary to refer to; any and all unicode characters are possible.) By the time the user gets this far, he has already defined the vowels / consonants in his language and some other configuration. There is then an iterative process of (1) the application guesses which syllables exist in the language based on some rules, (2) the user refines the guesses, selecting the correct parsings or manually parsing a word, (3) the application "learns" from the user's feedback and makes smarter guesses, (4) repeat until the data is "good enough" to move on.
The control needs to present each word (the grey headers), then all the syllable break guesses (the white areas with dots separating the parts of words.) There is also a way to manually enter a parsing, which will display a text area and save button (at the bottom of the mockup.) When the user hovers over a guess, the background changes and "accept / reject" buttons appear. Clicking on the accept, or entering a manual parsing, removes the entire word from the list. Clicking the reject button removes just that item.
I'm by no means 100% sold on the formatting I have above, but I think you can get a general idea of the types of formatting and functional control I need. The control will also scroll vertically--there may be thousands of words initially.
My question for you experienced WinForms developers is: where to start? I would really, really like to stay within the .Net core framework and extend an existing control as opposed to a third-party control. (At the risk of starting a religious war: yes, I suffer from NIH-syndrome, but it's a conscious decision based on a lot of quick-fix solutions but long-term problems with 3rd party controls.) Where can I get the most "bang for my bucK" and the least reinventing the wheel? ListView? ListBox? ScrollableControl? Do I need to go all the way back to Control and paint everything manually? I appreciate any help that could be provided!
[Edit] Thanks everyone for the ideas. It seems like the most elegant solution for my purposes is to create a custom control consisting of a FlowLayoutPanel and a VScrollBar. The FlowLayoutPanel can contain instances of the custom controls used for each word. But the FlowLayoutPanel is virtual, i.e. it only contains those instances which are visible (and some "just out of scroll"). The VScrollBar events determine what needs to be loaded. A bit of code to write, but isn't too bad and seems to work well.
I would look at the TableLayoutPanel and FlowLayoutPanel controls. These will let you organize a series of controls with moderate ease in a vertical fashion. I would then create a UserControl that consists of a label and 2 buttons. The UserControl will expose properties like Text and events that are exposed for the button clicks.. For each entry in the list, you will create an instance of the UserControl, assign the text value, and handle the click events. The instance will be placed in the Table/Flow panel in the correct order. Both of those layout panels do allow for inserting items between other items so you can add/remove items from the list dynamically.
Edit:
Given the length of what you are trying to render, I would consider using the DataGridView and do some custom rendering to make it perform how you want it to work. Using the rendering events of the DGV you can merge columns, change background colors (like highlighting the dark gray lines), turn on/off the buttons, and handle changing the grid into edit mode for your rows to allow modification or inserting of new values. This method would easily handle large datasets and you could bind directly to them very easily.
Well, this certainly looks like a candidate for a custom component that you should be creating yourself. You can create this using standard .Net drawing commands along with a text-box, and a regular button control.
Now you want to find out where to start.
Create a Windows Forms Control Library project.
Drop in the textbox and the button control.
The panel drawing code should preferably be done by code. This can be done using the regular GDI+ commands.
Edit:
Here's another idea, and one that I've practically used in my own project with great success.
You could use a web-browser control in the app, and show your data as html. You could update the source of the web-browser control based on the input in the textbox, and clicking on the links in the web browser control will give you the event that you can trap to do some action. Your CSS will work.
I used this technique to build the 'desktop' in an app I made called 'Correct Accounting Software'. People loved the desktop so much that it is one of the best loved features of the app.
Here's how I would do it:
Create a custom control. In this custom control, have a ListBox atop a LinkButton, and when the LinkButton is clicked you can make it give way to a TextBox. The ListBoxes will have the top row unselectable... you can probably get the rest from there. When you get your list of words, fill a Scrollable of some kind with one control for each word:
(foreach String word in words){
myScrollable.add(new MyComponent(word));
}
From there, I'm not sure what you want to do with the boxes or the data, but that's my initial idea on the UI setup.
Use the WebBrowser control and generate the HTML markup into it using DocumentStream or DocumentText.
What would be a good user experience to present this? I have:
A folder/directory structure containing mostly media files that need to be presented in a Silverlight app. Future versions may be expanded to allow some non-media files to be presented as well. The typical use case (that I'm tailoring the solution for) is video.
The videos (or pictures) have thumbnails. Videos can potentially have multiple thumbnails (i.e. if you hover over them you can see thumbs from multiple points in the video... this may make the screen appear too "busy" though).
There is a name, and possibly a little metadata associated with each. Audio files tend to have a lot of relevant metadata. I've never used metadata for video files and find the metadata-based indexing of videos that Winamp et. al. do to be fairly annoying. There are not comments or descriptions.
It is possible to sort the lists, and they don't necessarily need to be present in the hierarchical structure (i.e. search folders or folders based on particular attributes are possible -- although would it really be useful to allow a user to have a folder for all videos longer than 20 minutes?).
Thumbnails will be retrieved from the server as needed (when they are scolled into view)
Here are some random ideas:
A one-panel list-like view with fairly small names and icons based on file type (so, basically an explorer-like interface). Possibly columns, though the disparate media types makes sorting on columns fairly useless. To get more info and a thumbnail, the user hovers over an item, which pops up details and a thumbnail if available. Single-click advances.
A two-panel view. The left has the same structure as above. A single click selects an item and displays its details in the right pane. A double-click selects an item or opens a folder.
Specific modes/filters. First, the user selects a media mode (i.e. video or audio). In a video mode, the items in the lists become larger and a more "YouTube-like" view is displayed. Clicking on a video brings the user to a separate screen containing the content. Alternatively, videos can be displayed tiled in this mode. The audio mode has a playlist editor, play/pause/stop controls, and works more like a traditional media player with drag-n-drop, etc. Picture mode allows easy access to slideshow viewing. The audio mode will allow sorting by metadata (artist/album/etc.) rather than folder structure.
(Possibly in addition to one of the above) a "quick search" feature a la Google Desktop/Windows Vista+/ etc. Typing a name will pop up a list of results from anywhere in the index matching a substring there. Pressing enter will automatically play/show the most relevant file.
Any ideas? I want the focus here to be simplicity and ease-of-use, NOT features. iTunes, real player, even YouTube, etc. tend to like to be at the forefront of user attention. I'm looking for simple and streamlined.
I would argue that the simplest approach would be to use the design most are familiar with: a treeview on the left for folders with a collection of thumbnails for the current folder on the right. In addition for video, you could make the thumbnail play (either the video in its entirety or a small representative clip) when the user selects it.
There's nothing wrong with leveraging design that already works. It makes your application more approachable for new users and thus increases your attach rate.
Look at Infragistics' Quince app for more UI Patterns. In addition, there is Jennifer Tidwell's book "Designing interfaces" that provides a great reference.
What do you think is the best way to present a hierarchical list of functionality to users within your traditional WinForms application? (A menu system - Assume functionality can be split into a small number of modules and sub-modules but with no fixed depth in terms of those sub-modules).
Do you like the traditional drop down menu system, ribbons, docked toolbars, a treeview approach or any other innovative ideas?
An important thing to consider in your design is Usability vs Discoverability.
The best solution depends strongly on who you users are. The UI requirements for a kiosk application for tourists in a city centre are very different to those for a control screen at a power station...
I often have a toolstrip docked on top for those functions that is most used. And all other as drop down menues with hotkeys set.
If I have a list that can contain different types of items I use a bottom docked toolstrip that change its content depending on the selected item in the list. That way I only have buttons/icons that is relevant for the task and not a bunch of disabled buttons irritating the view.
I also add a context menu for the items that automagically fills with the same choises as the bottom toolstrip. That way I give a faster way to get to the "action" without having to move the mouse down to the bottom of the screen.
I really hate the ribbon-thing (as a user) so I dont use it as a programmer in my projects.
In my opinion the best way is to make sure everything can be done in several ways.
Menus
Keyboard shortcuts
Toolboxes ...
So the user can choose it's way around.
What I really like to see in more application is that a menu or option is directly attached to the selected item (control) a user is looking at. And of course the menu is in context with the given content.
I have implemented this in my open source project Monex and I really like using it myself. Just look at this screenshot.
You could always opt for the increasingly ribbon control. Microsoft/Office interfaces have a habit of becoming the user's expectation of norm (eventually).
Menubars, toolbars, and Ribbons are used for commands, where the user selection of an item acts on a data object displayed in the window or the application as a whole. Which one you use depends primarily on the number of commands in your app.
Toolbar alone: About 20 or fewer commands. Provide both icons and text labels for each command button. Represent the hierarchy by separators. Have no more than two levels –flatten your hierarchy accordingly.
Menubar with toolbar: Over about 20 but less than about 1000 commands. Up to twenty menu items on a single menu (using separators) is generally better than cascade menus –flatten your hierarchy accordingly. Common commands should have accelerators. Generally limit your toolbar to no more than 30 of the most commonly used commands, primarily commands otherwise only accessible from within a dialog box. Consider not having toolbar controls for menu items that have accelerators –one good means of expert access is often sufficient.
Ribbon: Over 1000 commands. A Ribbon is little more than putting different menubars-and-toolbars on separate tabs. To work well, the tasks associated with each tab (the top of your function hierarchy) should be non-integrated –users relatively rarely switch from one to the other. The Ribbon is also tends to be more effective for promoting discovery of advanced features at the price of discoverability and efficiency of basic features.
Check if items in your function hierarchy may be better represented as attributes rather than commands. Commands carry out a process, such as Open, Find, and Copy, while attributes change specific characteristics of something, such as Font, Size, and angle of view. Attributes are set by field controls within your window (e.g., text boxes, check boxes, and dropdown lists) rather than menu items, toolbar controls, or Ribbon controls.
A window-full of such field controls (or other representations of data objects) is a content block. Tree controls may be used to control what content block is shown. Like tab controls, they are preferred over multiple windows when the user frequently switches among the content blocks and does not compare content blocks. Trees are preferred over tab controls when the amount of content will not fit in a single row of tabs.
Do not have any empty nodes in your tree. Anything the user clicks on should display a full pane of content –flatten your hierarchy accordingly, even going to the extreme of using a list box rather than a tree.
If users tend to select one content block, complete a task there, then leave your app, then consider a “home” page displaying a full-page menu of all the content blocks, possibly spatially arrange according to your hierarchy, each accessible with a single click.
In my opinion there is no definite answer to your question. It always depends on the menu you are presenting to the user and the users that are expected to use the application
A menu with standard/common functionalities is probably best presented Office style meaning drop down menus or the new Ribbon style.
A menu with custom functionality and, as you state multiple modules and submodules with different depths, is often best presented as a TreeView-like menu.
Looking from the point of the user, a typical user will do just fine with a standard menu whereas a more advanced user won't mind more advanced features like keyboard navigation or possibility to hide/show the menu or dock it to the other side of the window.