I need a user interface that allows users to sort a table according to multiple columns (e.g. sort by color and then price within color, or alternatively price and then color within price). The only such interface I'm familiar with is the dialogue box found in Excel under data > sort, but this is rather clunky and does not yield itself to quick switching between views. I would much prefer an iTunes-style interface that allows quick sorting by clicking on column headers. However, such interfaces typically only allow sorting by one column (an exception is iTunes itself which has a very limited, apparently hard-coded ability to sort by "Album by Artist" and "Album by Year" by clicking on the Album header).
I can envision an interface where each column header has some numbers, such that clicking on 1 makes the column the primary sort key, clicking on 2 the secondary key, and so on. Alternatively, clicking (or right-clicking) on a column header could bring a drop-down menu with "primary sort", "secondary sort" etc. However, I've never seen such an interface implemented, and I don't have a good intuition of usability issues that may arise.
Are there applications that allow sorting by multiple columns using the column headers? Would you be able to point me to these? Are there any useful usability results regarding such interfaces -- which work better, which less so?
Also, while I am mostly interested in the specification of the interface, any hints to pass on to the people implementing it would be appreciated, e.g. publicly available libraries that provide parts of a solution (especially Java).
Edit: Two people have suggested using an Excel-style dialogue box. This is not going to work. For my application, users need to find the "best match" among existing table entries (which is often not a perfect match). The table is too big to keep in your head, so you need to keep scanning the relevant parts, and it's useful to repeatedly sort the table in order to get multiple views. Having to go through a dialogue box with multiple options for each change of view is just too slow; by the time you're done with the box, you've forgotten the results from the previous view.
I think Outlook supported sorting by multiple columns. After you clicked a columnheader, you would then shift-click additional column headers. I no longer use Outlook so I can't verify this. Hopefully it will be a starting point for you.
I've seen the shift-click interface that caparcode mentioned in a few applications, however I can't name any right now. Here's a nice web-based example though.
I would suggest using a Ctrl-Click (or Shift-click or whatever-click) approach to let the user select multiple columns. Clicking without Ctrl will just sort by the selected column, but holding the Ctrl-key adds the column to the sorter. Clicking again changes the direction. And give a feedback about the current sorter(s) similar as in these pictures. Most of the time the users will only use the single column sorter anyway, only advanced users will want to sort by multiple columns. But you should have the behavior documented somehow in the manual and in the "did you know" thingy.
But since users don't read, there is the risk that nobody will find the feature. But for this maybe you could have a feature like Windows when first started wanting you to click the start-button once to ensure you found the button. When you see the user not using the sorter at all, show him that clicking the column header will sort. Later, when you see he's not using the multi sort feature show him once that the feature exists.
Do it the way Excel does, or rather the way real people use Excel, which almost never involves that clunky dialogue box which you rightly wish to avoid. Basically, Excel preserves your current sort order as much as it can - so if you currently have it sorted in descending order by price, and now you sort by color (using the A-to-Z button on the toolbar*, NOT the dialogue box), the prices within a color will remain in descending order.
This approach does require a bit of reverse thinking from the user, because you sort first by the least important column, but it is very intuitive once you get it. (Yeah, I know, that sounds self-contradictory, but I don't know how else to describe it.)
To implement it, you'd have to store the user's sorting history somewhere; but as far as the interface is concerned, all you'd need is an up arrow and a down arrow in each column. Or, if you only want to allow A-to-Z sorting, just make the column headings themselves into links or buttons or whatever.
* Yes, I know the default Excel toolbars don't have A-Z and Z-A as separate buttons anymore, but one of the first things you do with a new installation of Excel is customize the toolbars to add these as well as Paste Values, right? Right?
How about the following? A single droplist labeled “Sort” in top margin of the table. The dropdown lists all fields to sort. Each field appears twice, once for ascending and once for descending sorts. Beside the dropdown is a button labeled “More” or perhaps simply “+”. The user chooses the field for the primary sort key from the dropdown. The sort is instantly applied (no “Sort” command button). If a secondary sort key is desired, the user clicks the More button and another dropdown list is inserted and opened for the user to select the second key. Additional lower order keys may be added with successive clicks of the More button. Dropdowns each include a “Clear” item to delete a key.
This makes a compact, simple, and uncluttered UI for the simplest and most common case of a single sort key (unlike Excel’s Sort Dialog or having numbers to the column headers), while also supporting the sorting an indefinite number of keys (again unlike Excel’s Sort Dialog). The user can see the sort order at a glance (unlike Excel and more easily than with numbers in the columns). It avoids the clunkinest of a dialog box.
Clickable column headers is a de facto standard that is also a good idea to include along with the above. It’s good practice to do what Outlook and Windows Explorer do and make lower order keys out of former sort orders. So, for example, if the table is sorted by date and the user sorts by category, then the table is sorted first by category and then by date. A user can thus do multi-ordered sorting by picking the lowest order sort field first and working up. However, this has poor discoverability and user may find that working “backwards” is counter-intuitive, so it should be supplemented with something like the dropdowns and More button. Relying on shift-clicking or ctrl-clicking likewise has discoverability issues.
Have you taken a look at Excel? That's a perfect example on how to sort on multiple columns.
Also, I use a detailed listview sometimes, and let the user hold the Ctrl key while selecting one or more columns to sort the info. (Clicking twice on a column does a descending sort.)
Seriously, what you want, Excel does. Why not use an interface people already know how to drive. I would suggest that. Or else you're going to either have to buy from a third party, or roll your own.
Development with Office is facilitated by VSTO (Visual Studio .NET tools for Office). It's up to you how much you want to automate Excel within an inch of its life :). It can be done.
In fact that is what I had to do. I had to read spreadsheets, extract data, convert to objects, then persist to Access (don't ask). Each sheet represents one record, and each directory represents a location, you get the idea. All done using the Office PIA Interop assemblies.
Just a thought.
Related
I did some experiments with MF_MENUBARBREAK, but with this I can only achieve two columns at the top-most level of the menu.
What I want is a menu like this:
It is not the full menu that I want to have two columns, but have two menu (Left and Right) items in the first line. Every other entry will ocupy its own entire line. Is that possible?
No, this is not possible. The native menuing system does not support "split" multi-column menus.
If a drop-down menu has multiple columns, then the entire drop-down menu will have multiple columns. Otherwise, all of the items are displayed in a single column.
You cannot have this (unless you mock it up in Paint like I just did):
Instead, all of the items that come after the one for which you've set the MF_MENUBARBREAK flag will be displayed in a second column. For instance, if the "Right" item has the MF_MENUBARBREAK flag set, your menu will look like this:
You can't get items "One" through "Three" to appear as if they were not in one column or the other. If you added the items before "Right" (the one with the MF_MENUBARBREAK flag), they would all be in the first column, like this:
…but they are still in a column. There's no way around that, short of owner-drawing the menus yourself, which is way more work than it is worth (trust me).
Perhaps you could just duplicate the numbered items under the "Left" and "Right" categories? As long as you gave each of the menu items a unique ID, it wouldn't be an issue to differentiate between them in code.
But then you would still need to find some way to indicate that "Left" and "Right" were column headers and should be treated differently from the items underneath them. I guess you could disable them and/or draw them in bold, but that's still not guaranteed to produce an intuitive UI.
Better yet, I would recommend keeping your "creative" UI design compulsions to a minimum and just adding another top-level menu. Users know how to use top-level menus. They already grasp this mental model. They don't really know how to use your weird custom menus, and anything weird is likely to trip up your users more often than not.
Users also (sort of) understand sub-menus, so you could still have a single top-level menu with "Left" and "Right" items that themselves display sub-menus containing your numbered items. But the usual rules apply—don't nest things too deeply, etc.
On OS X, I've seen something like the following menu structure:
It works well there, where users are accustomed to it. And as a programmer who likes to see things properly nested and placed into categories, I quite like it myself. But I'm not sure how intuitive it'll be to Windows users, for whom it'll be rather unusual. You'll have to do some usability testing.
I’m working on an inventory display app (master/details) for Windows Phone 7 where the user has the ability to change the sorting. The source of the data is XML from the web, and depending on the sort chosen, the results are either a flat list (sorted by name, model number, etc.) or grouped by the selected attributes (color, size, etc.). I'll pre-determine whether the sort returns flat vs. group and it won't be user selectable.
I’m displaying the results in a WP7 pivot control and want/need the different sorts to appear in the same PivotItem (putting the sorts in different PivotItems isn’t really an option). The source for the list is an Observable Collection (actually at this point it’s a CollectionViewSource, but I’m not wedded to either). I’m using the MVVM Light framework.
I’ve played with LongListSelector from the Silverlight Toolkit and it looks like it does what I want. I've read a number of posts (starting with WP7 ListBox Grouping) and actually have it working for the flat list (no sort applied, just default as it is from the source). Now I’m trying to figure out the right way to use it.
My questions:
Is it possible to re-structure the way the data is displayed (flat/sorted vs. grouped) without having to build/maintain multiple observable collections of the same info (one for each sort variant)?
If not, is the best method to save a local copy of the data locally on the phone and work from there? I expect I'd take a hit on complexity but pick up savings on perf/responsiveness.
To display the various results in the same PivotItem, should I create user controls with the appropriate formatting and swap them in to the pivot based on the chosen sort, or can I do it via dynamic ItemSource & ItemTemplate changes?
Is Observable Collection/CollectionViewSource the way to go here?
It’s entirely possible (even likely) the answers are staring me in the face, but I’m new to this stuff and I’ve hit data overload. I could really use some guidance.
Thanks,
Rich
Is it possible to re-structure the way the data is displayed (flat/sorted vs. grouped) without having to build/maintain multiple observable collections of the same info (one for each sort variant)?
I think what you could try is using LINQ to query your given collection, and use that query as the source for your LLS. I'm not sure on how the performance would be, but you can give it a try. Alternatively, IIRC the various *ViewSource collections have ways of changing the view of your data, so you can check those out.
I have a "sort by alphabet" icon in the application bar. If the list of items is currently listing:
1
a
b
Then should the icon show what the listing is currently sorted by (A-Z) or what it WILL be sorted by if you press the button (Z-A)?
The only example I can find on the phone is setting the volume to ring or vibrate (If it is set to ring, it shows a bell) but would like more examples / confirmation from people here.
If it's clear how the list is currently sorted by looking at it then I'd recommend displaying what the list will be changed to by pressing the button.
If the list can be sorted in any ways other than just ascending or descending alphabetical order you will probably need a button for setting each of the sort orders.
If it's not clear how the list is sorted by looking at it then this indicator should be separate.
Overall I'd question the value of having this sorting functionality. If you have a long list I'd use the LongListSelector from the Toolkit and then always have it sorted A-Z. This will simplify your UI (by not requiring a button to change the sort order) and will require less code.
If the button is closely associated visually with the list, like a column header is with a column in a grid, then I would say you could show what the current state is just like headers in columns of grids tend to do that offer this capability.
In this case, whichever way you do it, I would say the user would adapt fairly quickly by looking at the list to see how it works. There will be some who initially expect one way, and some the other I expect. Arguably there isn't a correct way to do it. It's a good idea to look at what other apps on the platform are doing, but there may not really be much to go on just yet.
The visual cue in this case is the tight visual association of the list and the button, suggesting to me that that button reflects the lists current state and that you can press to change it.
If however you had some form of a label that the button was associated visually to, then that button's text could provide the necessary context and your decision could be driven by that. For example your label could read "change sort to" or it could read "current sort is". This probably offers the most clarity, alleviating unsure users of the need to press the button a couple of times to learn how it works, but comes at the expense of valuable screen real estate.
If you walk into a hotel and your room number is 301, you want to go to the 3rd floor.
So you step inside the elevator and press the '3rd floor' button.
Therefore I think buttons should always show possible options, not the current state (i.e. ground floor).
So I think the button should show 'Z-A'.
I'm working on a comparison website, so needless to say the search function is the primary feature of the site. I have two input text boxes and a search button. At the moment, the input text boxes use Ajax to query the database and show a drop-down box, but I'm wondering if it would be more intuitive to use a select box instead? The second box is dependant on the first, as when the first is selected theres another ajax query so only the available options for the first selection appear in the second inputs autocomplete box.
Autocomplete
Pros:
- "Feels" right?
- Looks more appealing than a select box (css design)?
Cons:
- the user has to be instructed on how to use the search (made to think?)
- Only really works off the bat with javascript enabled.
- The user may get confused if they type in what they want and no box appears (i.e., no results)
Select Box
Pros:
- Can bring up the list of options / know whats available from the outset.
- We use select boxes every day (locations etc.) so we're used to how they work. (more intuitive?)
Cons:
- Can look a little unaesthetic when theres too many options to choose from. I'm thinking maybe at most around 100 options for my site over time.
Any thoughts on how I could go about this would be appreciated!
You will have 100 unique options? My guess is that those can be classified in some way. You already have one dependency in you form, adding another to produce a dependency chain seems like it would be intuitive. I've seen dependency chains used in a few places and they work well as it helps the user do a step by step restriction of the search space.
I also think that form should follow function, so Pros list for auto complete is weaker if you follow this philosophy. Also, one of your pros is an abstract concept that you couldn't put into words when writing the question, so the list is weaker anyways.
hmmmmmmmmmmm
Select box looks kinda weird, it could be right choice if there are lesser options, but it would be non influential if you had 100's option in it. The thing that user are also not into the habit of seeing something like this could make this thing worse.
On the other hand you can out something like no suggestion or make text box red when no match found.
What would be the appropriate way for selecting a particular row in a paginated view.
For example, while trying to select a particular row in Yahoo Inbox you can use the pointer to select the check box and if you try to click beyond the check box, no action is taken.
But while trying to select a particular row in GMail Inbox you can use the pointer to select it or if you navigate away from the checkbox it changes into a thumbnail but allows you to select the row.
Which method is preferable from a usability perspective and how to implement the thumbnail based selection as done by GMail
Both methods are appropriate, and both can be very usable.
I think the main difference is that row selection (the system used by Gmail) is more like a desktop application and a little less web-like. With links (like in the Yahoo inbox or StackOverflow), it's completely obvious that you're supposed to click on them. With rows, you sort of have to figure that out that you can click them, but I doubt it takes people long.
One thing to keep in mind is that, if you go with row selection, it's probably a good idea to bunch together any other clickable control (like checkboxes, links, or "favorite" stars). This way, you can click anywhere on the row. If you intersperse controls along the row, you increase the likelihood users will make clicking errors (aiming for the row but accidentally clicking some other control), and it will make it harder for users to recognize that the row itself is a clickable region.
So, both are perfectly acceptable user interfaces. You'll have to decide which one is a better match for your particular situation. I think, in general, links are a little bit more versatile, but with clickable rows, you know you can click anywhere and it will work.