New chapter: be transparent

content/books/things-i-learnt/_index.md

@@ -64,6 +64,7 @@ template = "section-contentless.html"
 		* [Not Just Function Composition, But Application Composition](application-composition)
 		* [Even for Application Composition, Start Stupid](app-composition-stupid)
 		* [Logs Are For Events, Not User Interface](log-events)
+		* [Be Transparent With The User](transparent)
 		* [One Version To Add, One Version To Remove](add-then-remove)
 		* [Learn To Monitor](monitoring)
 * Community/Teams

content/books/things-i-learnt/add-then-remove/index.md

@@ -30,4 +30,4 @@ deployed _at the same time_ as the new interface; by adding the new link
 format in another field, we can deploy the backend easily without breaking the
 current system.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/log-events", prev_chapter_title="Logs Are For Events, Not User Interface", next_chapter_link="/books/things-i-learnt/monitoring", next_chapter_title="Learn To Monitor") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/transparent", prev_chapter_title="Be Transparent With The User", next_chapter_link="/books/things-i-learnt/monitoring", next_chapter_title="Learn To Monitor") }}

content/books/things-i-learnt/log-events/index.md

@@ -43,4 +43,4 @@ could have the values to try to figure out why it failed -- surely, logging
 why it failed also helps, but you know what I mean. This is an example of
 something that makes complete sense in logs, but not in user interfaces.
 
-{{ chapters(prev_chapter_link="/books/things-i-learnt/app-composition-stupid", prev_chapter_title="Even for Application Composition, Start Stupid", next_chapter_link="/books/things-i-learnt/add-then-remove", next_chapter_title="One Version To Add, One Version To Remove") }}
+{{ chapters(prev_chapter_link="/books/things-i-learnt/app-composition-stupid", prev_chapter_title="Even for Application Composition, Start Stupid", next_chapter_link="/books/things-i-learnt/transparent", next_chapter_title="Be Transparent With The User") }}

content/books/things-i-learnt/transparent/index.md

@@ -0,0 +1,30 @@
++++
+title = "Things I Learnt The Hard Way - Be Transparent With The User"
+date = 2019-07-31
+
+[taxonomies]
+tags = ["en-au", "books", "things i learnt", "ux", "ui"]
++++
+
+Since we are talking about [logging](/books/things-i-learnt/log-events),
+another thing you must do is to be transparent with the user in your user
+interface.
+
+<!-- more -->
+
+And by "be transparent", I meant that your website/mobile app needs to point
+out to the user that the webserver is down instead of saying to the user to
+check their internet connection; your application _is_ getting something from
+the webserver, so you _can_ say "Oops, something wrong on our side".
+
+Another example: If you need to check a bunch of data before saying "It's
+done", add a counter to show the user that the application is doing something.
+[Joplin](https://joplinapp.org/), when syncing data with a webdav server,
+needs to check a bunch of files; one version would simply sit still with a
+spinner on "Syncing" and nothing more; when they added a counter, I could
+easily see that there was something going on.
+
+Those small details, for as bad as they may make you look, will win points
+with the user in the long run.
+
+{{ chapters(prev_chapter_link="/books/things-i-learnt/log-events", prev_chapter_title="Logs Are For Events, Not User Interface", next_chapter_link="/books/things-i-learnt/add-then-remove", next_chapter_title="One Version To Add, One Version To Remove") }}