Tag Info

New answers tagged

1

Kudos on getting a sound user research done and framing the question well. The problem here is that Apple assumes that the users know of the affordances. Ideally though, there should be signifiers denoting the said affordance. You've given some thought to this already and have come up with reasonable solutions, so I'm merely expanding on your solutions ...


1

Rather than mixing many icons into the table it may be easier to use them as the header label (with a tool-tip on hover), and a simple check mark to indicate that a user has this role. I think that this approach allows for uniform column width and will make the table far more scannable.


0

If your users will visit the list frequently and the roles will be maximum 10, then I recommend that you use icons and mouse over tooltips for their descriptions. Icons are much more superior than words for a quick visual scan. After a few interactions your users will learn the icons and their meaning. Otherwise if the users will not visit the list ...


0

If the list is so big, i think that multiple columns with icons is not functional. I prefer to add their roles with checkbox choice.


0

Simplifying your data when in a table is crucial to readability. When I make a front-end table, I use the same principles as if I would be doing a SQL table to some extent. If it were a database, you'd have a new item per role. instead of one enumerator that returned, or a csv. So in your table I would do that. What I think has happened to you here is you ...


0

In principal the use of icons (on their own) to convey complex concepts is a very difficult enterprise because they are prone to multiple interpretations, so would strongly suggest identfying larger groups of roles rather than specific roles. However, if you intend to use icons, you need to include labels to make sure that the right meaning is conveyed. ...


0

You say "could have up to 10"... But how many do most folks have? If most have 1 or 2 roles, you could show up to 2 icons plus a " more" link for those who need it. Another thought is maybe users could identify their primary role, then just display that icon with a link to "more" when needed. This way too, you are showing only the highest value info ...


2

You are right to be worried about the number of icons becoming too large. Unless you can find icons that are really obvious, this will become overwhelming for the user. You could try splitting the roles up into a small number of categories, and assigning an icon to each category. For example, you could have a "management" category represented by an icon in ...


0

The best option here depends on what your user needs to do. 1. If it's important to be able to quickly skim the list to find a Founder, it makes sense to put Founder in its own column like your second example. You can glance down any of the member type columns and quickly find the ones you're looking for. 2. If it's important to quickly learn about an ...


0

The problem with using icons is that you are requiring the user to have an additional cognitive load of trying to remember which icons relates to which user group and as the user scans down the table, he will no longer have the header as the textual indicator of what each icon stands for. Instead of going with icons, I would recommend going with a ...


0

I have had the same challenge in quite a few designs in recent years. If the interface involves drag-and-drop (for reordering), I personally have found that the most usable way of adding an item was also by using drag-and-drop. This was largely after testing a multitude of solutions, including a (design-award-winner-type) mobile application called Sooner. ...


0

I'd suggest a context menu would give the best experience. In all likelihood other functions will emerge over time that pertain to an item in the list. (To complement your "Insert below", "Insert above" springs to mind straight away—not to mention "Delete".) Enabling the user to invoke such functions by right-clicking an item would allow you to avoid ...


0

As a user, I would often find it unnerving if the UI behaved in unexpected ways. Instead of having the new alarms pushed on top, you could consider one of the following: Show the items beyond the current scroll (I'm assuming the modal window has a scroll?) out of the view of the user; he can then scroll up to see the new alarms. The top border could light ...


2

Have you tried combining the collapsable accordion along with a detail view? It gives a nice fluid feeling, especially when the expand/collapse animations are done properly:


1

You could use a scrolllist for the FAQ questions instead of a accordion. If you press e.g. on "Question 3" the detail view for question 3 is moving smoothly from right to left. If you press on "< Back" the FAQ list is moving from left to right. In addition you can offer buttons to switch to next or previous question in the detail views. download ...


0

Accordion can be a good solution, if it would be combined with some kind of categories. You can just split all your questions to 4-6 categories for example. You can also use any other layout instead of accordeon, but categorizing is a must in any case here.


0

This seems more like a development question than it is UX. The limitations of datatable you described are specific to that library, not UX. The "thought you had" is exactly what datatable offers on the demo on their website. If it has the limitation you described, you are probably looking for a different library, rather than trying to solve a UX problem. ...



Top 50 recent answers are included