Tag Info

New answers tagged

0

I would say definitely sacrifice the images on mobile. Don't think of it as a sacrifice though, just an efficiency :-) You'll never cater for the full breadth of mobile devices with a large menu and images - keep it simple and get the users where they want to go. By the looks of things the links have very concise titles so the images are just for aesthetic ...


0

I am missing which website we are talking about. Depending on that the process can be shorten or longer. I would suggest to first do an inventory list and have a full list of all the sitemap. Then in order to redesign the IA and if possible to also combine pages together this flow might be useful: create personas list the main use cases create the ...


1

I agree with others that it's a base design issue but if you can only change the top bar... Because of the colors used in the navigation of the "current product," you should use color to separate the product navigation from the current product. Use colors to disable buttons. You could left-justify the top navigation to separate it further.


1

None of the above? I mean this in a constructive way. Issues: You have 3 layers of navigation onscreen at the same time, which is pretty complicated for users. On top of that, the visual layout is confusing because you have a top navigation, and then a break for page title, then 2 more layers of navigation that are visually related by the tab idiom ...


0

I think split screen looks great as an idea, but is very difficult to implement in reality. So that's why you don't see them very often. For example, many sites are designed to be responsive nowadays, so while a split screen looks good on the web, it's very difficult to get it to work on mobile screens because the columns become too narrow to work with.


0

Additionally for clarity, one could also try altering the messaging of the "Home" button in the tabbed navigation, given that's the primary area a user will think to navigation. For example, you could try something like: Home - Accounting I also agree a combination of mockups A & C would work, with the underline being the most effective visual cue. A ...


0

First you need a communication strategy in phase with the strategic plan of the organization. The messy look of the IA is probably the consequence of no focus, no concrete objectives and too many people deciding what to put on the web site. The result is cacophony. Your first task is to get to know what this web site is supposed to do. Matt is right. Next, ...


2

Version C, with the underlines, is superior because it does not rely purely on colour but also has that additional visual clue. That makes it more accessible to people who have difficulty or simply cannot interpret differences in colour. I would however include colour as an additional clue in addition to the underline.


2

I think you're missing a key step which is audience personas. Who is the IA marketed at and what are their needs? When you have that, you can think from the users perspective. Then i would do card sorting from the audience point of view. You also need to have a concrete objective to make sure everything relates back to what you want to achieve.


0

Working on a project with a quite tight schedule and a complex IA structure we decided throw great chuncks of the previous structure over board –– to break with big/great ux strategies and boil things down to the following probably a bit unorthodox approach: First things first – and the rest will follow. We first identified the key functionalities / the ...


1

Keep them in separate navigation areas. Group all event-related actions in one toolbar, and give it a prominent position in the design. Keep secondary actions in a secondary nav area. download bmml source – Wireframes created with Balsamiq Mockups


0

In this case is better to use a widget that slide down, so that the user can continue his task on the current page. Lightbox are better in case you have to interrupt the user journey and redirect the user to a specific part of the website, for example a My Account section.


1

Let's start with some principles: It's ok for the help page to look different. In many cases, it may actually be desirable for help to look different because it (a) provides contextual assurance to users that you are acknowledging their need for help; (b) user flow in help is totally different from user flow for the rest of the site (e.g. in an XBox ...


0

Each interface has to be optimized for it's goals, and for those goals ONLY. The goals are different, so the interfaces would become different if you follow that rule. It does not make any sense to show the marketing content to the user who has already bought the product (unless you have some exceptional situation). It's just irrelevant. The other main ...


0

User taxonomy is different from company taxonomy This is a common trap in UX design. Companies may organize their products a certain way, but may fail to understand how users perceive their products. For example: a company may organize its products by category (shoes, pants, shirts) but users may prefer to find and discover products by brand and by ...


0

Ideally your detail page represents that entity you want to represent. It should have everything you can do with that entity. That screen is the super-set of whatever functions you have on that entity. Having an operation on search result screen is a shortcut which you are offering. This is a good thing. This enhances usability by offering an option to ...


0

It's not normal, I don't have research to support this though, when you are editing a form and you delete it what happens next? Do you get redirected to the list page? What happens if you already had some fields edited before you pressed delete? I personally don't think it's a great idea


2

Working within the constraints you are providing, I would suggest: shortening the name "Blogs & Columns" to just "Blogs" to make more space. shorten "Destinations" to "Places" or something else? Those two combinations might give you space. That said, I think you have quite a busy nav bar already, so I'm not sure if it makes sense to try to add this ...


0

If you want to seal a deal don't block users from viewing content until they have reached "point of purchase" Amazon only asks users to login at checkout! Login walls require a significant interaction cost: users must remember their credentials (if they have an account) or take the time to create a new account. Therefore, sites should use them ...


0

Side bar with a home option. Reason: when user goes through hierarchical menus he knows what he's doing and he would need to go back in most cases. So having home button anywhere on screen all the time is bad idea as it occupies some unnecessary space. Only when he finds himself wrong he needs a home which he can open the side bar and tap the option.


10

You should (although it may be hidden in some scenarios). There are two things to consider: Mobile first You are basing your design on the current presentation - that's a reasonable thing to do, so long you remember that the presentation might change on other devices, like, say, a mobile phone. On a mobile phone the tabs may be collapsed under a menu, in ...


1

Put a "Skip Navigation"or "Skip to main content" Links first element before every thing on top of your pages. So the keyboard user will decide to let screen reader go through all navigation and other stuff or just skip to go to the main content. so you can use visuallyhideen class to make the link invisible for sighted people. ...


0

First, in English the word information is plural, and doesn't need the "s" at the end. Is there a good reason to force the user into this sequence of tasks? Can these things be done asynchronously? If you are constrained by this complex sequence, I think displaying the steps as rectangles that expand when you are inside a task with sub-steps might be a ...


1

If it links to another page, why not use the standard link analogy? The convention is well known for users. Otherwise a small symbol next to the row title in Tohster's solution would also work. download bmml source – Wireframes created with Balsamiq Mockups


0

I think it's hard to solve this problem without changing styling or adding elements. However, you may be able to indicate the navigation in a way that minimizes the impact on styling. The basic issue here is, the section titles and row headers are perceived as passive because they almost always are. Therefore, you will need some kind of indicator to ...


0

Some questions you should ask... Is this a highly complex process that requires so many steps? Sometimes it is... e.g. I'm signing up for a new mobile plan and number. Most of the time it's not. Either way, always ask if you can simplify the flow. Are there info that don't need to be collected at this point in time? Or you can handle it with a set of default ...


6

Great question, and a common design problem. There is no "right" answer here, but here's a contemporary approach: This looks like a commercial website. So, reducing cognitive friction for potential buyers is important. You likely have a large number of users who are new to the site, so providing consistent affordance in your controls (especially in a nav ...


0

the browser back button MUST work as expected. your web UI back button MUST NOT provide a back button unless it does the same thing the browser back button does example: filtered category view in ecommerce - if the back button return to unfiltered category view it MUST NOT look like a back button, but rather like a breadcrumb. you SHOULD provide ...


0

Speaking not as a designer but as a user; anytime I have to default to my browser's back button to continue navigating a site, I can't help but consider it a failure of the site's UX. The more I have to use it, the more frustrated I get. The only exceptions are instances like "What was that seller's address on the last page?" or "What did I put in that form ...


0

No, you shouldn't rely on the browser's back button. While its easy to say that you can expect it to be present and that you can expect it to always function a certain way, that's simply not the case. Because the back button exists in an application outside of your own, you can't reasonably expect it to be present or function in any specific way. If ...


10

This is a bug with the Google UI, and not intentional. You were right to notice the distinction, but it shouldn't be used as any kind of example of good design. As of now (March 2015), Google is in the middle of a long process of migrating its apps and platforms to Material Design, and it will take a while before most apps are compliant. Material Design ...


2

Technically, the upper and the lower part belong to two different software products. The upper one implements the UI to the user account, and handles the navigation. The lower part belongs to the current application. I assume they where created at different times. Between these, there was a change in the style guide used, regarding how to style tooltips. ...


0

I would go with the native tooltip if possible (if you're not trying to do a fancy tooltip with icons or colors). This will be most familiar to users and you don't have to worry as much about accessibility, etc. in the way you do when you use a custom solution.


6

I'm pretty sure it's because Drive is developped by another team than the team who's working on the Google account canvas. More a question of schedule/production rather than UX/UI thought I guess.


1

I don't have an authoritative answer BUT the two tool tips refer to different environments and Google's designers might have wanted to differentiate between them. The first, "plain," tooltip is for Google's main navigation section. The second, "styled," tooltip is for the individual app within the broader Google environment.


7

Rely is the wrong word You're asking if you should rely on the button, which you shouldn't. You're also asking if you should offer another option. Which you could, and in certain situations, should. So here's the thing: Back button You should never, ever, break the behavior of the back-button. At all times, you must strive to keep it's functionality in ...


48

A web application should always strive to be compatible with the browser's back button. That is, using the back button should have deterministic results within that application that match expected behavior (global consistency). A common scenario that comes to mind with this is an eCommerce site that has a list of products. A user clicks on one of the ...


0

I wouldn't use it exclusively. The first example that comes to mind is Google Chrome for Android. Every "tab" is a new instance, and so opening a new window is akin to starting a brand new session. In these instances, the back button will simply take the user to the homescreen instead of actually going back. The same thing will happen if a user chooses ...


-2

You should rely on the browser back button but not exclusively! Best case scenario: back button on the screen support for browser back-button


25

Yes. You should rely on the browser back button. Users expect the button to be there, so make sure it's functional. But should you mimic the same button with its functionality? If your application or website needs it, yes, but not always exactly the same. In some cases, like your example of a webshop, a button that just says back or an arrow might not be ...


0

I believe that you should not rely exclusively on the browser's back button. If the user is interacting with your site to get somewhere, I think it's reasonable they would expect to be able to return the same way. Displaying where the user is within the context of the website is important so the user has a frame of reference where they are in the overall ...


3

I usually try to provide both on-screen back-button and support for browser back-button. Reasons: If the user is immersed in the flow of the app, an on-screen back button can help keep focus inside the flow and avoid losing the user's attention. Supporting the browser back button is important to me, even at great cost, because it's presumptuous design to ...


0

Link labels that match page titles are a clear navigation cue for users. However, page titles are often longer than what can be used in a navigation set. In that case, I try to use at least one of the key words from the page title in the link label. You have a bit more space in buttons and CTAs to be descriptive, but you should always tell the user what to ...


1

I don't necessarily see an issue with a page title being a verb phrase, if it accurately describes what's happening. The example given in the question ("Map Streams") seems perfectly valid to me. That said, I can think of other examples where it would not be logical for the page title to match the referring call-to-action. If I press a "Go to checkout" ...



Top 50 recent answers are included