Choose the layout that suits the type of content you’re displaying. A
list style layout is for the seated because users' actions tend to be
very singular in purpose. They've come to your site to do one thing:
browse or read. Present them with content in a standard way and let
them just get lost in it.
On the other hand, grid view is for the ...
The Android design resources are a pretty good resource to look through.
If a frequent or important action within the context of that screen is to add a row then you should consider putting it in the main action bar. From the Android guide:
Show the most important actions of your app in the actions section. Actions that don't fit in the action bar are ...
I cannot give a comprehensive answer, but there is one very important case where the table is superior.
Sometimes we have lots of equally structured items (that's an important precondition!) and need to display lots of information about an item in an UI which supports multiple tasks (or multiple scenarios of the same task), but only one piece is relevant ...
One important aspect is that a tile layout makes it easier to analyse the items one by one (a) while a table makes it easier to compare the items (b):
The power of getting all the data around one content item in one separated layout item is not to be underestimated. The analogy between the two entities makes it a lot easier to focus on in and make a ...
You can use two actions in a row, Apple does support that with its standard UI elements. Its called the Detail Disclosure button.
Users tap a detail disclosure button to reveal additional information
or functionality related to a specific item. The additional details or
functionality are revealed in a separate view.
From IOS Human Interface ...
There are multiple ways to approach your problem. But first of all, I'll give advice that cannot be given often enough:
Get rid of clutter first. Especially in a "data intensive" environment.
The rule of thumb here is: If you have more than about 7 columns you're doing it wrong. Look at every column, find out if you actually need it and come up with ...
If the question is taken at face value, i.e. strictly a choice between the →/↓ arrows or the +/- signs, then I suggest using arrows.
Arrows denote the direction and a sense of movement to another place or view.
+/- signs could be construed as meaning add / remove. For example it looks like I can add a manufacturer, or add an Extra item. While, the minus ...
In Illustrator and Balsamiq (i know, they are not scientific tools) the clone action is Ctrl+D (on Win, on Mac it's Cmd+D). While in Illustrator it's actually "repeat transformation". But you can use it for sort of "cloning".
D can stand for "duplicate". So probably instead of labeling the action "clone", you could label it "duplicate" and put Ctrl+D as ...
I've been researching for many weeks about this topic and my conclusion is: IT DEPENDS.
When the users make their first search (or homepage with products) they may want to see a large picture with few details to visually compare one from another. This applies to similar products (like shoes, jackets, furniture, etc). But if your e-commerce application is ...
Best practice may not apply to a location
There may be enough examples (Google Analytics and Podio are two more) that place toggles like this to the top and right of the content to say that it's a conventional location, but I'd argue that the location of controls like this should depend on the specific application and user goals.
Examine your motivation ...
From a UX perspective, it looks like the table you've got is a bit dense for a smartphone screen. I would start by figuring out which of these columns people are going to want to browse by. Are they scanning for a particular concept ID, or are they going to want a list sorted by type, or are they reading all the descriptions? If you answer those questions ...
I'd suggest trying to find an UI pattern that fits this purpose - so users are familiar with it, and will find it intuitive to click there to 'expand' and have more content.
In your case, perhaps 'card expand' according to Google guidelines (Material Design? is a possibility?
You can either get rid of the outer thumb div or size it to the same size as the actual image and put a little padding around it then use a flowing grid pattern, sometimes call a masonry layout.
Here is a source for doing this in CSS:
It depends on how and where you want to use the list. As a best practice for better usability, it is best to represent a list with alternative row colors for each list item - this makes it easy to read, which makes even bigger difference in a list of sentences as user can read each sentence and know without any confusion where it ends and the new one begins.
Your second suggestion (and as per your image) are perfectly usable and meets the requirement to be able to browse the list and jump to a specific point.
Usability trumps 'looking a bit weird' in this instance.
However, depending on your use case, another option would be to split all the neighborhood into expandable panels so that the user can scroll up ...
I think you can, regardless of the phone OS. If you take a look at Windpws Phone Call History, you have two different actions on the same row. The first item is an icon of a phone, and on key press you will call that person. The second item is the name, which on key press will lead to that persons contact information:
But to make this work you'll need a ...
The root of your problem is that your system involves 3 states, two of which has functionality constraints (the non-manual sorts).
As such, your task is to convey the constraints to the user in an optimal way.
One (of many non-optimal) options I can think of is to have drag handles that will be greyed out in non-manual sort. But this requires ...
I don't see a problem with it.
'Consistency' doesn't mean 'sameness'. Users can handle changing interfaces just fine so long as they understand the change and there's not many states for them to remember, and changes don't compound on top of one another.
After all, no-one complains when only some pages on a website have a scrollbar, or when a context-bound ...
They'd add visual appeal and might add functionality as well. I can tell from a screenshot which page on my site is being referenced more quickly than I can scan the URL.
A visual way to browse popularity by screenshots could be interesting. http://pttrns.com is a site about design patterns, but the overall style (big pictures, minimal text) ...
The tradicional Windows Grid is not recommended for that use. There's a guideline for search purposes:
Start app page
You can use auto suggest, but filter should be placed with the results
Here's an example of how your results list could be.
Kinda like this
For more Windows guidelines info:
Since you're working on WinForms that means that you're actually on a Windows Operating Systems. In your case with multiple choices I would go with the more conventional Windows style and use Add and Remove arrows, as the mockup below tries to explain.
download bmml source – Wireframes created with Balsamiq Mockups
Most Windows users, and especially ...
Tog already replied to a similar question at Ask Tog.
I agree with JonW.
Although this might seem redundant, it supports browsing and searching in a graceful way, without getting in the way.
Another interesting side effect is that it provides a better way to browse than an scroll bar would. Instead of having to scroll until you find a visual cue ...
For me the only reason to avoid the single search (2nd option) would be to have several columns with similar content, thus leading to an inefficient search.
If that's not the case I would totally go with the single search:
There's only 1 entry point for search, thus less cognitive load. The users only have to think what to search, not where to search it.
I find the search box more intuitive for search. However, the text boxes provide a way of advanced filtering. So, the question is - do you want your users to search or filter?
If you want both, you may consider the following intermediate solution, Amazon is using the same. Your search box searching all columns by default but the user has the option to ...
There's a very good article on UXMatters about filtering information in tables. Although old, it still makes a lot of sense. A few options have been considered, like data filters above a table:
filters to the left of the data
or tabular format in case the number of filters is low
There's also a good discussion about consistent availability and visibility ...
Floating arrow button pointing "UP" when you pass a certain scroll height seems to be the standard way.
That behaviour is also used quite a lot in chat/messenger apps, especially when there are new messages and you have to scroll down to find them.
If you have long content a back-to-top link can prove useful. However, for normal content, users will ...
I agree scrollbar breaks the two sides when they are connected. So, I would make them not connected visually and simply put the details in a separate "space", beside the list. It can be within a border or just simply the text beside the list, like this:
I'm pretty sure people will understand the two sides are connected when they first click on any item in ...
Use filters to view outstanding items, and an archive can show a 'Sent' history and timestamp.
Since you have a potentially long list, give the power of filtering, so that states that are urgent 'Pending', 'Waiting', etc... are shown with the number of items outstanding.
Filter the view so long lists can be dealt with.
If you have their address, you can ...
I'd suggest using a circular progress bar with the number / percentage written inside of it, this way you are giving your users a more accurate information, meanwhile also making sure it's still quick to scan. Something like this: