Episode #125 of the Stack Overflow podcast is here. We talk Tilde Club and mechanical keyboards. Listen now
74

I very often work in such projects, and the answer is a resounding YES, and as early as possible. People find it much easier to criticize improve some draft than to come up with a solution from scratch. So I start drafting early for two reasons: Give the matter experts an impression on how the information could be presented. Show my current understanding ...


56

1. UX: message boxes are mostly evil Alert boxes are bad in all cases from the UX point of view. In desktop apps. In web apps as alerts or inline JavaScript messages. Everywhere. You can read About Face 3 by Alan Cooper¹ if you want to know why; it explains very well how does this interrupt the workflow and annoys the user, and how nearly every alert box ...


39

Mockups are fantastic and there is no reason a dev shouldn't do them. (It can even be handy for a dev to do a rough draft of a UI layout even when you have UI designers on the project.) I highly recomend you don't make mockups that look like actual screens. If you share these with end users that often focus on things that don't matter like colors and ...


34

what to show to the user. Should this also be hidden from the user? You show the user what is actionable for them. For example, if you have an error which is caused because of some null pointer exception and more of a bug than user error you don't want full explanation because they can't do anything different. Or should we show this anyway? Or should ...


33

It matters a lot. Good UX increases productivity. If UX is good, the company can focus on "how to do their stuff" instead of "how to use your software to do their stuff", and it takes less time to teach new workers. And, good UX will drastically decrease the number of support tickets, so you can spend more time on resolving serious issues rather than "how ...


30

Right now I am browsing this website through my company's VPN which gives me an English IP. While I am in fact a native Hungarian, working physically from Hungary. Is this a good enough example? ;-)


17

Several reasons: The person using the browser may not speak the language that the browser uses. (Say, someone who is French on an English machine...) The location/language information may not be accurate (for any number of reasons: VPN, proxy, etc.) You could call it laziness on the part of the developer(s), EXCEPT that it is always best not to ASSUME, and ...


17

The sites that do are really really annoying! Google who are pretty much the state of the art as far as Web UI is concerned get this consistently wrong as far as I (and many other people) are concerned. I travel a lot and it really annoys that I need three clicks to get to "google.com" Intial www.google.com which redirects to www.google.co.?? with all ...


16

They have released a UI framework that supports ribbons -- it's just supported in MFC instead of .NET. There's probably room for quite a bit of debate as to why they did things that way, but it is what they did anyway. It looks like Metro-style apps will be supported much more universally -- not only C++, but also C#, VB, and Javascript are supported, if I'...


15

I had similar experiences with you. I believe the following dynamics/factors are in place with enterprise software and UI. As stated in another answer the person that will sign the purchase of the software is different than the person that will use it and different that the person that will maintain it. So purchase is made based on "features" or some other ...


15

Animations can be an extremely important part of the user interface. They communicate or hint at things a user can do, guide the user through the application or help build up a well defined mental model of the application inside the user's head. Consider the classic iPod interface, where screens slid from side to side to signify the navigation through a ...


15

However in Scrum you are only supposed to have user stories that provide value to the user. Value isn't measured only in lines of shippable code. You seem to be implying that having a well designed UI doesn't provide any value. Of course it does. Obviously there's value to the end user, but there is also value to your development team, which is a ...


15

This is hard to implement because of the definition of what is healthy You answered your own question here. The definition of a health check is going to vary, because what is healthy varies. It also depends on what is issuing the healthcheck. A good question to ask yourself is, "from the perspective of the asker, is the checked service working as expected?"...


14

A common reason for this "feature" is that a site tries to keep some state of the current session on the server side. That desire to track "conversation" state on the server side often comes from trying to write a Desktop-like "rich client" on the web (as opposed to embracing the web as the chaos it is). To be fair, this mostly happened in a time when the ...


14

It's consistency, or also "principle of least astonishment". However, your less formal definition seems fine too, more pragmatic.


13

I'd say neither. Provide a form where they can report some feedback. Behind the scenes, this form can send you an email, create a github issue, or whatever you want it to do. You can also provide the github link - an asterisk at the end of the page if the users want more information about the current status of the issues. I don't think providing an email ...


13

Take it iteratively. You're working directly with the users, right? So it should never really be a mess. First do the search page. You and the users should keep in mind that they'll want to be able to do actions on the results. Do the users like it? OK, you've got your search. Now add the "Change Password" (or whatever is next in priority). Oops, we ...


13

Never trim whitespace arbitrarily in an API. The only reason to ever trim whitespace arbitrarily is as a UI feature. People frequently leave spaces at the end of entered fields but can't see that they've done so. It's pretty confusing to return a message, so -- except in the rare case where a user might enter "A " to mean something other than "A" -- you can ...


13

The main disadvantages are these: You are pipe-lining: if your designers are late, your developers are left without work; if your developers are late, your designer will eventually work more than one iteration in advance. It's not a stable situation - it is not sustainable. Your designers are working in advance, you are paying costs for stories that may or ...


13

The problem is that a password should appear in plain text as rarely as possible. In your case, the password appears in plain text in an e-mail. This has several drawbacks: If the account of the person is compromised, the hacker gets access to your website as well. If there is a malicious man in the middle, he can access the password with ease. Moreover: ...


12

Absolutely it does - only the trouble with "Enterprise" software is that it is sold entirely on feature sets, to managers who don't have to use it (or even look at it), by smarmy salesmen who know all the tricks of getting such software sold. This is one reason why a lot of companies moved to open-source software - apart from the other reasons like cost, ...


12

Checked exceptions are a failed expriment in language design. They force you to have extremely leaky abstractions and dirty code. They should be avoided as much as possible. As for your points: 1) Checked exceptions make the code dirty, and no less unpredictable because they show up everywhere. 2) How is a checked exception being shown to the user any ...


12

It depends on who the user is, and what they can do with the information. Generally, try to show them only useful information about things they can resolve themselves. A 40 line stack trace with a regular expression error at the top is not very useful. Much better would be a message that says Date must be formatted as "yyyy-mm-dd". Anything else, and the ...


11

Is this request technically viable? No, not least because technical users will be able to spoof the requests - that said those users that are capable or walking round the limitations are more likely to be using a browser that doesn't cause you problems. Is this request reasonable? Maybe - but I refer to my earlier answer, the users that can easily ...


11

Yes, absolutely. Don't let someone else tell you how to do your job. And you are right, it's very much like doing UML for your data model. Assuming you are a developer, your job is to deliver quality software. If mockups help you do that, then that's part of your job. Do low fidelity mockups -- don't make them look like real screens. You'll waste too much ...


10

Users tend to stick with 1 or 2 passwords. If the app was hacked by another app, then having the user's password from your service might grant access to other more sensitive resources besides your food service. A better method may be to store some sort of long term authentication token on the phone than the password itself. That token could be tied to the ...


10

The best solution in this case (and it is mentioned in the question) is simply to remove, or even better, to disable the UI elements that lead to "Access denied" actions. This way, the user will know that they can't do this action. Additionally, some hints can be displayed on these elements that to explain: "Disabled, because this action requires more ...


10

When designing "a new screen", you want to discuss the rough idea of the UI first with a user and/or your colleagues. You cannot discuss this with a user "in code" or "in UML", that simply does not work (it won't even work between programmers). And you should expect that you need to throw away your first two or three scetches, or at least rearrange the UI ...


9

You could use an application to draw mockups instead of writing code. Like Balsamiq Mockups or equivalent. Using Mockups feels like drawing, but because it’s digital, you can tweak and rearrange easily. Teams can come up with a design and iterate over it in real-time in the course of a meeting.


9

I would not force an update on a user. First, it tends to happen that someone's "work flow" or "process" becomes dependent on certain behavior of your app. If you change that, it will cause chaos and anarchy and whining to someone's boss that those mean IT people are stopping me from doing work and they need to fix it NOW. Secondly, like you said, ...


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