“As discussion of a failure grows longer, the probability of a comparison involving my action at Waterloo approaches 1—that is, if such discourse should persist for a sufficient period, be assured that some self-styled wit will compare someone or something to the second fall of the Corsican Tyrant.”
While I’m developing the new UI for OurAirports.com on my laptop, I want to be able to test on various mobile devices easily, including other people’s devices (where it’s rude to root and mess around with /etc/hosts). Here’s what I did:
dev.ourairports.com pointing to 192.168.0.5./etc/hosts file, hard-code dev.ourairports.com to point to a 127.0.0.* IP address.With these steps, the domain dev.ourairports.com will always work from my laptop, wherever it’s connected, and it will work from other devices when I am on my home WiFi (anywhere else, it will probably bring up something strange, like a router or printer login page).
I’ve played around with Docker a fair bit, but I’m still happy just running a bunch of VHOSTs for different webdev projects, and so far, it hasn’t caused me any grief.
Does anyone have better suggestions? Any gotchas I’ve missed?
or … It’s always been a struggle for control
Time: 1980s
Place: TV
Time: 2010s
Place: the Web
(To be continued …)
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:
https://www.fedex.com/ca_english/services/moneyback-claimform.html
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.
Update from Dustin DeWeese: “A working Emacs 25 package is available in Termux: https://termux.com
$ apt install emacs” — this is probably a better solution than the outdated distro below.
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.
/data/, where you can make a file executable and run it (you cannot normally make a file executable under /sdcard/)./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)./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
/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 -
#!/system/bin/sh 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).
chmod 755 emacs
*.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
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.
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:
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.
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:
| Location name | Location code | People affected |
|---|---|---|
| #loc | #loc_id | #aff_num |
| Town A | 01000001 | 2000 |
| Town B | 01000002 | 750 |
| Town C | 01000003 | 1920 |
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).
While HXL is still in the alpha stage, the Standby Task Force is already using it as part of the international Ebola response, and we’re running informal interoperability trials with the International Aid Transparency initiative, with planned more-formal trials with UNHCR and IOM.
We also have an interactive HXL showcase demo site, and a collection of public-domain HXL libraries available on GitHub. More news soon.
Thanks to the Humanitarian Data Exchange project (managed by Sarah Telford) at the UN’s Office for the Coordination of Humanitarian Affairs for giving me the opportunity and support to do this kind of work, to the Humanitarian Innovation Fund for backing it financially, to the HXL Working Group for coming together to figure this stuff out, and especially to CJ Hendrix and Carsten Keßler for their excellent work on an earlier incarnation of HXL and for their ongoing support.
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:
https://data.hdx.rwlabs.org/ebola
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:
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
or
Media»Music»Classical»Beethoven
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.
Do breadcrumbs perform an important function in modern web design, or are they just a crutch for bad design?
Quoderat 