When might a company decide that web usability is a bad thing?
If I were a conspiracy theorist, I’d suggest that companies deliberately sabotage forms for tasks like refund requests, to discourage user conversion. Practically speaking, however, I think it’s more a matter of just not bothering to invest in them past the alpha stage. Consider FedEx Canada’s refund form:
Every field on this form is required, even though many of them won’t apply (e.g. you might not have your own invoice number associated with the shipment, and you almost certainly won’t have a fax number), and some are actually contradictory (you will have either a FedEx Express Air waybill number or a FedEx Ground Tracking ID, but not both).
On a higher level, nothing in the form makes it clear whether you’re filling in your address or the address to which you were sending the package. Flip a coin!
Fortunately, the form also doesn’t bother with data-type validation, so I was able to put “n/a” in all the fields that didn’t apply (1995 called and took away my fax machine), and I was able to guess that they wanted my address, based on the presence of a picklist for Canadian provinces.
If you’re an enterprising soul, you might consider setting up shop as a Web Unusability consultant, to help companies find ways to keep customers from filling out unwelcome forms.
In February 2014, I posted instructions for installing Gnu Emacs in older versions of Android. These instructions no longer work in Android L (Lollipop), because of a new requirement that all executables be compiled with a position-independent (PIE) flag. I have managed to create a new binary from Michał Zieliński’s admittedly now out-of-date patched Emacs version, and have made it available on GitHub.
Since TerminalIDE also fails to run under Lollipop (lacking PIE), the instructions for installation are now somewhat different.
Install some kind of a terminal emulator (JuiceSSH currently crashes, but others seem to work) in your Android. If you’re not rooted, then you must choose a terminal emulator that has its own home directory under
/data/, where you can make a file executable and run it (you cannot normally make a file executable under
Create a new directory
/sdcard/emacs/ to hold your non-executable files, such as eLISP files (you may choose a different location, but you’ll need to set some extra environment variables so that Emacs can find your files; that’s outside the scope of this posting).
₣rom my GitHub repo, download emacs.bin, copy it somewhere not on your
/sdcard/ (your terminal emulator’s “home” directory if not rooted, or somewhere like
/data/local/bin/ if rooted) and make it executable:
chmod 755 emacs.bin
From my GitHub repo, download etc.tlzma, terminfo.tlzma, and lisp.tlzma, and unpack them all into your
/sdcard/emacs/ directory — you may need BusyBox installed to get the unlzma and tar utilities required for unpacking, e.g.
unlzma -c lisp.tlzma | tar xvf -
Somewhere on your executable path (perhaps /system/xbin/), create a new shell script called “emacs” containing a command like this:
HOME=/sdcard TERMINFO=/sdcard/emacs/terminfo /data/local/bin/emacs.bin "$*"
If your chosen terminal emulator already has TERMINFO installed, then don’t set it in the script. You may choose any home directory you want, but it must be writeable (Emacs will want to create a
$HOME/.emacs.d/ directory to save settings).
Make the new script executable (and make sure it’s on your execution $PATH):
chmod 755 emacs
If your terminal type is unrecognised, you might need to add additional terminal types to emacs/terminfo; conversely, if your terminal emulator is already using a TERMINFO database somewhere, then don’t set the TERMINFO environment variable in your shell script.
Crashes in a local shell under JuiceSSH — don’t know why yet (use a different terminal emulator). Update: only when the font is too large — seems related to screen width.
*.elc files are earlier than dates on
*.el files after running Michał’s build scripts; you should probably fix that with something like this:
find /sdcard/emacs/lisp -name '*.elc' -print0 | xargs -0 touch
Starts with the message “WARNING: linker: /data/local/bin/emacs.bin has text relocations. This is wasting memory and prevents security hardening. Please fix.” — this seems to be a common problem in Android L, and I have not yet found the right combination of GCC flags to fix it.
Any volunteers to package all this up neatly, perhaps with some terminal emulator, for distribution in the Google Play Store?
I refer to these two comics constantly when I’m doing technology architecture and design work.
(From The Far Side, 1980s IIRC.)
This year, the UN gave me the chance to bring people together to work on data standards for humanitarian crises (like the Ebola or Syria crisis). We put together a working group from multiple humanitarian agencies and NGOs and got to work in February. The result is the alpha version of the Humanitarian Exchange Language (HXL, pronounced /HEX-el/), a very different kind of data standard.
What’s wrong with data standards these days?
Unlike most data standards, HXL is cooperative rather than competitive. A competitive standard typically considers the way you currently work to be a problem, and starts by presenting you with a list of demands:
- Switch to a different data format (and acquire and learn new software tools).
- Change the information you share (and the way your organisation collects and uses that information).
- Abandon what is valuable and unique about your organisation’s data (and conform to the common denominator).
For HXL, we reversed the process and started by asking humanitarian responders how they’re actually working right now, then thought out how we could build a cooperative standard to enhance what they already do.
Not JSON or XML
Given the conditions under which humanitarian responders work in the field (iffy connectivity, time pressure, lots to do besides putting together data reports), we realised that an XML-, JSON-, or RDF-based standard wasn’t going to work.
The one data tool people already know is the infamous spreadsheet program, so HXL would have to work with spreadsheets. But it also had to be able to accommodate local naming conventions (e.g. we couldn’t force everyone to use “ADM1” as a header for what is a province in Guinea, a departamento in Colombia, or a governorate in Syria). So in the end, we decided to come up to add a row of hashtags below the human-readable headers to signal the common meaning of the columns and the start of the actual data. It looks a bit like this:
The tagging conventions are slightly more-sophisticated than that, also including special support for repeated fields, multiple languages, and compact-disaggregated data (e.g. time-series data).
Posted in Aid, Data
The humanitarian community’s response to the Ebola crisis is more transparent than many responses in the past, and that transparency includes data. The core datasets from the UN and humanitarian partners are starting to appear here:
If you do anything potentially helpful with the data (visualisations, combining with other data, etc.) please let the UN’s HDX project know, so that they can share it around.
If you’re a technically-oriented person (like most of my readers), you already know this magic spell, but I suspect it’s not obvious to most of the world: RCIM — right-click-incognito-mode (or LPIM — long-press-incognito-mode in mobile) lets you open a link without persistent cookies. That does a couple of pretty-magical things:
- It blocks tracking cookies (so Facebook’s database, for example, doesn’t know that you’re reading a piece on Unicorn herpes on another site if you didn’t follow the link from FB), and
- It circumvents many (most?) quota-based paywalls (e.g. newspapers and magazines).
I’ve been reluctant to share links from sites like economist.com because of their quota wall (if I share a link, I want everyone to be able to read it). Browser extensions like AdBlock+ and Disconnect can solve at least the first problem, but I’m looking for something easy-enough for everyone to use (or at least, everyone using a browser with a incognito/anonymous-browsing mode, which describes most of us in 2014).
So #RCIM and enjoy a web with fewer barriers.
In web design, Breadcrumbs are those little navigational links you see across the top of some web pages, like
Home → Canada → Ontario → Ottawa
Breadcrumbs let you can see where you are in a web site’s information hierarchy, and let click to climb up to a more-abstract level. As of 2014-06-13, I use geographical breadcrumbs on OurAirports to let users climb up from looking at a specific airport to looking at the list of all airports in an administrative subdivision (e.g. province/state/governorate), country, or continent. I have haven’t changed the site design by the time you’re reading this article, you can try it out for Cairo International Airport.
I like breadcrumbs, because they reflect the way I think. I tend to organise information hierarchically, like a librarian, and breadcrumbs let me find my way around an e-commerce site (for example) without wasting time on frustrating searches. The article “Breadcrumb Navigation Examined: Best Practices & Examples” goes into great detail on different types of breadcrumbs and their benefits.
While I love breadcrumbs, I notice that not many people use them on OurAirports. People almost never click up to see all airports in the same province or country; they really just want to look at a specific airport. Are my breadcrumbs just wasting screen space?
Back in 2008, Jared M. Spool posted an article “Design Cop-out #2: Breadcrumbs” suggesting that breadcrumbs represent a design failure:
The biggest problem is the lack of scent for the other areas of the site. If a user is in need of breadcrumbs because they are in the wrong part of the information tree, what they need most is good scent to the right part of the tree. However, the breadcrumbs only communicate the branch they’re on — not the branch they need to be on.
In 2011, Shanshan Ma wrote in “10 Ways Mobile Sites Are Different from Desktop Web Sites” that even if breadcrumbs belong on desktop web sites, they don’t belong on mobile ones:
However, breadcrumbs rarely appear on mobiles sites, and there is usually no necessity for them. Limited space is one reason breadcrumbs are uncommon on mobile sites. But the main factor is that the design of mobile sites prevents users from having to go too deep into a hierarchy to find what they are looking for.
What do you think?
Do breadcrumbs perform an important function in modern web design, or are they just a crutch for bad design?