6.2 Simplicity is gold

Establish some rules about your app to be:

  • simple the app must be fast usable
  • straightforward easy to approach and use

Based on the identification of the destination of the app:

  • for professional use
  • for fun

The quicker you understand the interface, the better the user experience (in business)

Don’t fight against the app but enjoy it (for fun)

Yes and No of your app
YES
NO

Figure 6.2: Yes and No of your app

Yes:

  • “self-explanatory” but with detailed explanations
  • an efficient tool

No:

  • fight with interface
  • read complex material
  • lose time understanding how to use it

Two more important rules:

  1. “don’t make me think”
  2. “rule of least surprise”: “Principle of Least Astonishment”

6.2.1 How we read the web: Scanning content

The second part of this chapter focuses on what your audience is actually seeing about the app.

The user of your app doesn’t read everything, but will be searching for “How to”?

graph LR A((scan))-->B>satisfice - satisfy and suffice] style A fill:#bbf style B fill:#f96, stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5 #style P fill:#bbf,stroke:#f66,stroke-width:2px,color:#fff,stroke-dasharray: 5 5
scan
satisfice - satisfy and suffice

Figure 6.3: “How to”?

The user might act unexpectedly on you app

adopt “defensive programming” mindset is a workaround the unexpected:

  • inherent logic in the application: each sub-menu is designed to handle one specific part of your app

  • rational choice: rationality plays a good game but it is less than expected when up to a new app

  • “irrational” choices: examine the back-end for unexpected behaviors

"organisms adapt well enough to ‘satisfice’; they do not, in general, optimize.“ by Herbert A. Simon

To be failing gracefully and informatively can sometimes happen, but do not forget to put an informative bug message to avoid a grayish version of the application. Under some conditions you might not have the complete manner of all that is linked with your app (such as widgets in {DT} package)

Good practices:

  • add a bug message
  • wrap all server calls (in case of crash reduce the amount of data loss)
  • use a notification function with {shinyalert} and/or {attempt} packages

As an example, if we want our app to be connected to a database, we use connect_db() connection in the server().

If the connection fails, we notify the user:

  conn <- attempt::attempt({
    connect_db()
  })
  
  if (attempt::is_try_error(conn)){
    # Notify the user
    send_notification("Could not connect")
  } else {
    # Continue computing if the connection was successful
    continue_computing()
  }

6.2.2 Building a self-evident app (or at least self-explanatory)

  • self-evident: no demo required
  • self-explanatory: no explanation required

A. About the “Rule of Least Surprise” and the “Principle of Least Astonishment”

  • various text customization lead to conventional thinking

B. Thinking about progression

  • design a clear pattern of moving forward
  • hide elements at step n+1 until all the requirements are fulfilled at step n.
  • ensure some kind of linear logic through increasing readability

compare {tidytuesday201942} to {hexmake}

C. Inputs and errors

Your user is BUSY BUSY BEE ….

In the UI:

useShinyFeedback()

In the server():

showFeedbackWarning()
hideFeedback()

( the notifyjsexample repository link doesn’t work )