17

Main questions

  • Can you provide examples of implementations that implement the suggested solution below?
  • If yes, what are the benefits and drawbacks, especially as reported by users?

As the SE guidelines state, please back up any opinions with facts.

Background

I have multiple clients that have existing interfaces that basically are very complex forms. People that don't use these interfaces every day are intimidated by them. These clients are in the process of moving their interfaces to the browser, and we're using that opportunity to rethink the interfaces in general.

Heavily inspired by Google.com, I have suggested the solution below, which basically is a "command line appearing as a friendly search dialog". However, the concept is a big deviation from the existing GUIs. Some clients perceive the risk as too high, even though internal testing with other clients has been very positive, including phrases such as "oh my god, my jaw hit the floor". In order to proceed I therefore need to demonstrate that it has been successfully implemented elsewhere. Hence my request for example implementations.

The end users are lawyers, economists, engineers, clerks etc. that receives software training. However, some of the applications have hundreds of fields, making the applications unnerving for non daily users.

Suggested solution

Also see illustrations below.

  • Make the interface(s) read-only (while supporting selection of text).
  • Introduce a large, friendly-looking, Google-style input field at the top.
  • When populating key-value pairs (a major use case), allow the user to enter the value first.
    • Automatically derive the possible keys based on several factors, including the contents of the value (using regular expressions and dictionaries) and the assumed current use case. Present the keys as autocomplete options.
  • When submitting commands, allow this through the input field as well, employing autocomplete and synonyms.
    • Optional: When a command is selected, transform the input view into a simplified "command wizard", assisting the population of command parameters. Details below.
  • Provide power users the option to make all changes through this box.
    • Provide beginners the option to edit the individual fields directly (e.g. with a pencil icon appearing on rollover) while simultaneously and unobtrusively informing how this action can also be completed by the main input field.

Intended benefits

  • Familiarity: Interface is as similar to Google.com as possible.
  • Improved readability, reduced intimidation: The existing interfaces have up to 70 form elements per template. One of my clients have a corresponding read only view, and the more casual users tend to favor this one. When interviewed, they frankly state that the form-based template is intimidating.
  • More efficient, less strain: User does not have to use the mouse.
  • Focus on content: When entering values, the user oftentimes does not have to specify the attribute.
    • Batch entry: User can paste multiple lines of text into the form at once, and each line/paragraph will be mined for key-value pairs (activates dedicated dialog).
  • Improved registration workflow: Some of the existing templates support multiple registration scenarios. Dedicated registration templates have been considered as too costly in terms of development and maintenance. This interface should solve problems such as tab order for these conflict-of-interest scenarios.
  • Natural language: Using synonyms, users can initiate commands using their personal vocabulary, while being informed about the business' preferred nomenclature.
    • Guided process: The optional "command wizard" supports a dictionary-driven autocomplete, guiding the user when entering parameters. See illustration below. Moreover, the wizard further simplifies batch actions.
  • Embeddable: Like Fantastical's Mini Window, the miniscule input field can be integrated into other products. Outlook would have been a candidate for one of my clients (however, they are unwilling to do any kind of integration with Office due to technical debt).

Simplified use cases

Population of values

  • Use case: User wants to populate the Number plate field with value "DD12345".
  • Solution:
    • Keyboard focus is already in the input field.
    • User types (or pastes) "DD12345".
    • Several "autocomplete" rows, Google-style, appear beneath the input field. The top item is populate Number plate with DD12345.
    • User presses arrow down and Enter, selecting the autocomplete.
    • The value is correctly populated in the read-only view. A highlight appears and fades away.

Submitting commands

  • Use case: User wants to approve a number plate.
  • Solution:
    • Keyboard focus is already in the input field.
    • User types "app".
    • Several "autocomplete" rows, Google-style, appear beneath the input field. The top item is Approve vehicle DD12345.
    • User presses arrow down and Enter, selecting the autocomplete.
    • The system supplies a confirmation in a dedicated feedback field (not a pop-up). The vehicle status is correctly updated in the read-only view. A highlight appears and fades away.

Screen shots

Existing interface – 1st out of dosens of templates, several equally complicated:

enter image description here

Proposed interface – User issues command in the input field (presses p then arrow down):

enter image description here

Proposed interface – When issuing commands, the optional "command wizard" provides help entering parameters:

enter image description here

Improve this question
7
  • 1
    Great question! I have an identical project in my backlog right now. I haven't given it enough thought to form an answer, but I think there is a lot of potential in your proposed interface. You have quick entry and "recall" accounted for. Come up with a solution for "recognition" and you have a winner.
    – plainclothes
    Apr 13, 2016 at 17:23
  • 1
    @plainclothes "Recognition" must be addressed, yes. There's a chance that the read only appearance of the bulk of the GUI is a benefit in that respect, since all the original form elements contributed to the intimidation. I base this assumption on the observation that one of my clients already offer a read only view, and the casual users tend to favor this one, even though it can't help them edit their data.
    – bjornte
    Apr 13, 2016 at 18:38
  • 1
    Great to reduce complex forms, but it may be swinging the pendulum a bit too far. I note that this shifts the burden of knowing ALL names for form fields, employees, and functions onto the user, and assumes uniform knowledge & terminology among clients. Huge increase in cognitive load & recognition/recall as mentioned above. Perhaps also look at prior posts on breaking up long forms into sections, wizard patterns, etc? If I had to complete a bunch of 100-item forms with a 1-line search field I think I'd go nuts. I'd prefer 10 x 10-item steps. Good luck!
    – mc01
    Apr 13, 2016 at 19:28
  • 1
    @mc01 Re. "burden of knowing all names": The names (keys) are still present in the read only view, and then there's the edit affordance (the pencil icon) for beginners. Re. cognitive load: My take is that it may decrease since the user can express herself in her own terms, Google style, without navigating to a particular template beforehand. That's what the synonyms are for. Obviously, testing provides answers. Re. "breaking up long forms into sections, wizard patterns": Multiple registration scenarios leads to multiple wizards. Means increased dev. cost & tech. debt. Client resists.
    – bjornte
    Apr 13, 2016 at 20:14
  • 1
    Client resists separate views but will pay for natural language processing & building comprehensive synonym dictionaries? Ok then ... I like the 2nd example that seems to work like code completion - offers cues & prevents errors vs only a blank input. Dropdown and/or tab-complete to give users a clear place to start & speed completion. Instead of making the user remember function signature & parameter types/names, the system takes on that burden. Would opt for that as default vs the blank slate. Or would "Provision iPhone 6 for Bjørn with uID 12345" also work? That seems like lots more work.
    – mc01
    Apr 13, 2016 at 21:05

1 Answer 1

Reset to default
6

I think your idea won't work well. Primarily because if I first end up in an interface where I expect to fill in forms and see a search bar, my first thought will be that I'm in the wrong place, I expect form fields where I can input my data. Users won't know how to submit their data using your approach. They will need to be instructed or guided, which is a No No in usability. To say it in another words this approach violates the usability heuristic of consistency. When the consistency with other similar interfaces is violated users start to ask questions like, can I enter all of my data from single search field, where I can input my X value, where should I enter my data, etc.

You assume that because it is easy for you to interact with a console-like interface, it will be easy for everybody else. Thats a typical programmers mistake when they are developing UI. You know how to interact with it while users don't, and thats the big difference. UIs are not used by developers, but by users. Otherwise they would be named Developer Interfaces (DI).

If the users already knew how to use your search bar it probably would be easier to interact with. However, the problem is that they won't know how to start using it.

Instead of building a complex search bar, you should use the standard input form fields and take some care of optimizing them (removing unnecessary fields, leveraging default values, autocomplete, and other).

Improve this answer
5
  • 1
    +1 Yep, the fact that the Google search bar works is because its primary use is also basically its only use: search. The fact that you can use search to do a whole slew of other things (like starting a timer) most of these can in fact be seen as specific searches (converting currencies, translating) and augment rather than diversify the use of that input box. (Oh, btw, I am a developer/programmer and I abhor command line interfaces - OP addressed the main concern though: remembering, by auto completion/hinting)
    – Marjan Venema
    Apr 14, 2016 at 7:03
  • 1
    Why don't you separate the complex UI on Tabs?
    – Kristiyan Lukanov
    Apr 14, 2016 at 14:19
  • 1
    @KristiyanLukanov Agreed, that's a good principle in most scenarios. In the one with the grey screenshot, there are already more than a dozen additional templates, and the users work in a dual monitor environment, wanting to view a lot of the data simultaneously, somewhat similar to stock brokers. So one goal is to reduce the visual clutter while keeping the data.
    – bjornte
    Apr 15, 2016 at 9:05
  • 3
    I disagree with your first point. It seems based on the idea that things should not change. In fact your only real argument here is that "change is bad". While such a drastic change like this may be jarring to users at first, if it is something that will be used often, the transition period is largely moot compared to the operational efficiency that could potentially be saved in a new design. What really matters is the actual usability of each design. Your second point, however, is valid. Don't assume that because something is intuitive to the designer that it would be intuitive to a user.
    – devios1
    Apr 15, 2016 at 21:30
  • Hey devios, in usability consistency is one of the most important things to follow. Breaking consistency decreases usability simply because of how human brain works. Its much easier for your brain to process something that has been already learned, than something that is new.
    – Kristiyan Lukanov
    Apr 20, 2016 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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