1

I have been creating new ASP.Net web apps for my workplace intranet (it is a closed system, not accessible to customers) and also re-creating some existing Windows programs as web applications. One colleague always suggests that things work more like a Windows desktop program - things that would take extensive effort with JavaScript for example (of which I have only a small amount of experience) to implement, and which only the requestor is likely to notice. Our primary internal tools are all moving to a browser-based, externally mandated production system now, and so I have been following those standards.

This colleague always asks, "could there be an Hourglass?" for anything that is not instantaneous. Also, "could there be a piece of JavaScript that explains that it is searching?" or whatever the scenario is. I had previously done this for some particularly long-running pages. That is more effort than our in-house system needs. Another issue arose over how to update data. The suggestion was to have a button to switch to Edit mode, then save the data if the user navigates away or closes the page. But the web server doesn't know that you have closed the browser window or navigated away. (Yes, it could be done with JavaScript, but is not necessary.) Another request is for a message to appear on the page to say "Click Update to save your changes" as soon as any alteration is made to the data on the screen.

My approach when using ASP.Net for pages that simply edit a single row in a table (not insert or delete) is to have the DetailsView or FormView launch in Edit mode, with the standard link buttons labelled Update and Cancel at the bottom. If the user closes or navigates away, no data change happens - which seems very intuitive to me (and requires no code). The suggested way feels a bit like leaving the car in Drive when you stop and having it roll away when you get out of it.

Are my colleague's suggestions reasonable, or do they reflect a lack of experience with web applications? To me, these suggestions are not just inappropriate to the browser app situation, they are actually harmful. It would add lots of needless and error-prone development for me. How can I approach this? My manager has not heard these one to one discussions and likely has no opinion, but I will bring it up when possible.

28
  • 5
    Have you asked your users what they want? Jun 7 at 22:14
  • 3
    The fundamental problem is that things that were easy to achieve 35 years ago, or came with an application by default, have become difficult, long-winded tasks with web development. It's hard to avoid the conclusion that you're taking working Windows apps and substituting them with inferior web apps, because you lack the high skill and extensive experience necessary to reproduce the functionality that comes free in Windows. (1/2)
    – Steve
    Jun 7 at 22:44
  • 5
    The specific problem is likely not hourglasses - it's some means by which the computer indicates that it is actually busy working, because that matters to users. Similarly, the view mode/edit mode distinction is likely about avoiding unintended changes by the user being explicit about their intentions, and having been explicit, avoiding the unintended loss of changes (particularly where the overlapping windowed UI of a Windows application, has been replaced by something far less well-integrated). (2/2)
    – Steve
    Jun 7 at 22:44
  • 5
    It seems your colleague is specifying solutions instead of asking you to solve problems; Of course users who are familiar with one particular system will naturally explain what they want in the context of whatever they're used to, but you need to find out what their needs really are so that you can define the underlying problems that they have in mind instead, by focusing on what their goals are in using the system, rather than taking their attempted solution design as requirements. Jun 7 at 22:44
  • 2
    ... besides that, my usual approach for dealing with such requirements is to make a table listing each individual change request, try to give an honest estimate on how long it would take to implement, add a reasonable safety margin to it (especially when research would be involved), and also put a note about the alternatives in the same row. Don't forget to mention the features for which you think they are more important, and estimate them, too. Then make a priorization, with the people together in one room who have the authority to decide about the priorities ...
    – Doc Brown
    Jun 8 at 3:41
3

The requirements for a good UX on several points forms a positive criticism, and also are present in many if not most web applications.

However they are hard to program oneself, and (especially as there is a plethora of UX features) it would compete with time for business logic development. And JavaScript is not the most qualitative software basis. Even when being content with a mediocre user-interface, that part will cost much development and maintenance effort - doing it yourself. Repairing and improving user-interface can be both costly and unproductively.

So it would be best to use some framework, already offering such UX functionality. However for ASP.Net I have no experience, as I am on the other - Java - side. There are also some JavaScript frameworks modeling the application user-interface.

Make a list of UX features and research for a framework: make prototypes. The invested time will be rewarded by other peoply taking care of any UX problems and having a ready-to-use tool.

3
  • 2
    Yes, those were my thoughts in general. I was planning to use Bootstrap, because I had some familiarity with it, perhaps I should push in that direction. I started with a simple approach, but it might be time to advance. Jun 8 at 10:27
  • With web applications where the expectation is a responsive user interface, a good JavaScript framework for the GUI part is a must. Jun 8 at 12:34
  • I'll be looking at the new production system that users will be moving to for ideas for what in the UX to modify. Jun 8 at 21:38
8

User expectations should be taken into account when developing software but users are bad sources of UX/UI specifications. You need to have (or be) a UX/UI designer to design a UI that fulfills the various requirements and expectations. For in-house applications, a dedicated UX designer would most likely be overkill (unless your organization happens to have one who's currently not completely booked).

Your colleagues' expectations are actually not unreasonable:

  • "wait" indicators are pretty common in web applications. The visual language is a bit different (animated overlay instead of hourglass cursor) but the meaning is the same. Web pages that don't react either quickly or show some wait indicator make users feel insecure about their actions and may trigger unnecessary aborts or retries.
  • losing unsaved input data when closing a web page or browser (or using the "back" button) is bad. Many web applications detect this and ask the user if they really want to leave the page. Good UX would be to not only ask this question but explain something like "you entered name and other info, but that input isn't saved yet".

Since developing such UI features does indeed cost time and adds some amout of risk, there must be some sort of cost/value/risk assessment. It would be good if some "neutral" party would do that, not you as the developer or the user, because you're likely to be biased. In business terms, the manager approving the budget for this application may be qualified to decide, but they're also biased (economically).

3
  • 2
    "Good UX would be to not only ask this question but explain something like "you entered name and other info, but that input isn't saved yet"." I'd argue that good UX is more about unobstrusive features, i.e. auto-saving as opposed to a blocking message. You could even store it in a cookie (or locally) if the data is too incomplete to make it into the backend - which is what I think StackExchange does with written-but-unposted answers?
    – Flater
    Jun 8 at 8:03
  • 3
    Good comment, and in many cases auto-saving or keeping unsaved edits in local storage my be the right thing to do. In still other cases (especially when dealing with financial stuff or appointments) auto-save isn't what you want, and silently keeping unsaved edits isn't either. So it depends on the specific use case. Jun 8 at 8:57
  • In terms of "budget", just think of me as not completely booked and keeping an infinite, prioritized list of pending work. Jun 8 at 10:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.