Tag Info

Hot answers tagged

14

If you're working in html/css, the effect is really quite simple to set up: CSS can take care of both the alternating row color and the transition effect on a row-removal. A Fiddle demonstrating the working effect. The CSS establishes a 'base' green colour for each table cell, but then sets the cell background of every 2nd row (tr:nth-child( 2n )) to red - ...


12

This is an excellent question for which there is an excellent answer. Allow me to start with two examples. Colour and meaning Consider you are using a system and wish to delete a record (and you do wish to delete the record). The interface presents the following dialog to you: download bmml source – Wireframes created with Balsamiq Mockups ...


7

For the most part the pros/cons of this come back to the classic Adaptive vs Adaptable interface argument, where Adaptive interfaces automatically adjust based on user interaction, and adaptable interfaces allow users to manually tweak them. A problem with this in particular is that text size is an accessibility issue. Not everyone has the same eyes, so ...


7

Your questions seems a bit misleading for me. Is your question about: how the google+ circles layout is called? - there is no UX/UI pattern for this, Google+ introduced the new Circles concept "You can see that all rows are consistent and that if you resize the browser, the cards will rearrange to maximize the use of the space, making the rest fall down to ...


6

Cutting of the text with an ellipsis would be my first idea as well. Alternatively you could make the text "disappear" in the background by placing a transparancy gradient on top of it, i.e. so that the text fades away. It's basically the same idea but a little more elegant from a design point of view. Adding a tooltip that displays the full text could be a ...


5

The problem with dynamic interface elements is that it prevents the user from learning where things are. As they alter and adjust over time, the user is prevented from gaining mastery of the gui, as their learned behaviors become obsolete. Consistency is far more important than incremental improvements based on Fitts' Law. Some elements are consistently ...


4

I've always gone with the following rules to make this determination: If any action on the current screen/page/window will change the availability of the field, it should be disabled/enabled as the values/inputs change. If no action on the current screen/page/window will cause the field to be available, then the field should be hidden. If the information ...


4

I've heard it called a fluid or flexible layout.


4

In my opinion, dynamic examples based on the first characters user have entered may help users to enter correct values (validation is still needed, thought): Examples will not only suggest the way phone number can be entered, but also limit ways of validating this numbers (since there may be a lot of different schemes, so choosing one or two depending on ...


4

In both MooTools' and jQuery's userspace, this is called 'TextboxList', so it is very reasonable to use that name.


3

I agree with you. Both approaches have pros and cons. I would advise mocking them up, or developing a quick prototype, and testing it with a couple people, see what they think! (testing, testing, testing should be your mantra, when developing UI's :P ) But, in my experience, i'd advise you to keep the menus static, to avoid possible confusion on users: ...


3

Option 1, static tabs with helpful messages, should do just fine. Remember, your users aren't stupid. When they get instructed what the situation is (they should have more events for a certain tab to be useful), they understand it a lot better than the confusion created by tabs appearing and disappearing while they don't have a clear reason why that happens. ...


3

I would call it a list or tag builder.


3

I would keep the users place. The user will return to the application expecting it to be where they left it rather than having had it move arbitrarily up. You should notify them that more things have happened but keep the viewport focused on the last place they left it. this the way facebook do it with their activity stream on mobile, it keeps it's position ...


3

If your strips and your text aren't linked with some animation you could remove the annoyance. I guess it's even possible to work without uniform height if you wait for the text animation to finish before changing the stripes heights.


2

There is some inconsistency in you mockup. The groupbox' title reads "Locations", yet you only show 1 location's details. There should be an overview of all locations, where you can see all locations, which should have a button to add, delete and edit locations. Both the add end edit buttons should show your mockup, but instead of "Locations" it should ...


2

my suggestion: "add location" should be displayed below form (footer). It's more covinient - user completing the form, from top to bottom... and then can decide to add new location, "remove location" should be displayed as header of each location - on the level of current "add location". additionaly remove button should be similar to "add ...". in ...


2

I haven't heard of a golden rule unfortunately; it would be great if anyone knows of a study. A couple of thoughts and my experiences: Is the user interested in simply accessing the "child" field without going through a parent field that enables/shows it? If yes, than hiding the field might make it more challenging for the user to know that the option is ...


2

As I understand it, your search function and 'add' function are independent, i.e. the behaviour of the 'add' button doesn't change based on any search criteria that may be set. The problem you have is that a newly created object may not match the active search criteria and would therefore not appear in the filtered list once created. I have encountered ...


2

Provide a rich text editor toolbar like what you see here, and make a combobox-like selection of available placeholders. The more interesting part comes on the rendering of the edited text, as the placeholder is expected to be an atomic token, therefore two behaviours are wouldbe expected in my opinion: highlighted handling: usually, a "capsule", with ...


2

Do your best to rethink the grouping to slim down from 12 tabs to a smaller number, if possible. Is this part of a stepped process ? (like setup, creating a profile, etc) If so, I think 3 is the magic number in terms of the total number of steps. To slim down to 3, ask yourself 'do I really need this data ?' or 'do I really need this data now (can I ask ...


2

In option 1, they have to waste time by seeing options that are not related to the items whenever they want to manipulate an item, which results in slower scanning speeds. In option 2, you are repeating yourself and forcing customers to scan options that they aren't interested in when they want to navigate away. Once again slower scanning. Option 3 is ...


2

Users don't think in RESTful terms like this (Edit object, new object, delete object, etc.), developers do. So I'm not crazy about this interface in general. The better option would be to show the appropriate action on the "object" at just the right time in the workflow. But that's not your question :) Here is how I would handle it. I would put the Edit, ...


2

Textboxlist seems to be the most common name, although I find the following names a bit better, clearer: TagListBox LabelListBox


2

In my opinion, Brian North's Fiddle looks far less jarring, and suitably clear, without the transition. http://jsfiddle.net/wzBLB/


2

Smallhacker - Do you need the zebra striping to begin with? If it's to help the user scan across a wide row, maybe another design pattern would work? You could try "highlight row on hover". A list apart has two interesting articles about whether zebra striping is useful: Jessica Enders, “Zebra Striping: Does it Really Help?” at A List Apart, May 6, 2008 ...


2

A few suggestions: Cases should be rows, not columns. As bdimag already mentioned, there are some display problems with the current format, particularly when you can add an arbitrary number of cases. In addition, I would say that making the cases be rows would be more intuitive to the users. Add/edit cases in a pop-up overlay. The current "add case" ...


2

I saw this question, made some sketches, got distracted, came back to see that @dan1111 had described the majority of the fixes. In fairness though, all that's happening here is the application of some design conventions. The biggest variation is regarding the addition/editing of cases. I've proposed that the inputs mirror the data in the table. This could ...


1

As a tech demo it suggests many benefits. Most of the answers here seem to be concentrating on the negative impacts of what happens when you bring the device closer to yourself, thereby decreasing the fontsize, but I believe the benefits of this system are when you come at it from the other direction - how to present content to users viewing it where their ...


1

Not only is this invasive, raising numerous privacy concerns it also limits user choice. We shouldn't ever do anything that removes user choice. It's also based totally on assumptions about the visual acuity of the viewer as well as their preference of text size. It isn't sensible to make assumptions. There are tried, tested and accepted methods of ...



Only top voted, non community-wiki answers of a minimum length are eligible