Sitting in the airport during a layover on my way back from DebConf is one of the few times of year that time and motivation come together and routinely lead me to blog. Each year's DebConf has been special in its own way. This year at DebConf 12, in addition to the usual routine of catching up with all my far-away Debian friends, and of making new Debian friends in a country I've never been before, I got a special treat: my first opportunity to experience the practice of medicine in a foreign country. Last Saturday after arriving in Managua, I discovered that the very pretty paving stones making up the hotel walkway were also very slippery when wet, and the thin rubber strips that had been helpfully put in place to make them less slippery did not measurably succeed in doing so. So as it was raining that afternoon (as it does nearly every afternoon this time of year in Nicaragua), I slipped, and made the critical error of not falling. Instead, I stopped my slide - as it happens, by using the big toe of my left foot as if it were a roller skate brake. I don't recommend this, particularly if, as in my case, you already had it on your todo list to consult a podiatrist after DebConf regarding an ongoing feeling of weakness in precisely that part of precisely that foot. So while everything seemed fine the next day, Monday I woke up early with excruciating pain in my foot which, having forgotten about the incident two days prior, seemed to come from nowhere. After favoring the foot for another day and trying to keep the pain at bay using just OTC drugs, by Tuesday my foot was quite swollen and a source of concern. So I visited the clinic on the university campus, where the doctor diagnosed me with a dropped arch plus cellulitis due to bacteria entering through some invisible cut. Conclusion: university campus clinics are equally useless the world over. But at least in addition to pointlessly prescribing antibiotics, the doctor also prescribed some anti-inflammatory drugs to help bring the swelling down. Nevertheless, my questionable mobility kept both me and Patty from attending the day trip on Wednesday, which was a real shame as I had been keen to climb a volcano that day with my fellow Debian Developers (which in the end didn't happen for anyone, but that's a story for someone else's blog). Instead I took it easy for the day at the hotel, together with a few others who had opted not to attend the day trip, catching up on email and other work and hoping matters would improve. But by the end of the day the swelling was as bad as ever, if not worse, and I had no idea what was going on. Was it broken? Was something dislocated? And so I decided that the following day I would go to the hospital. The nearest hospital, as given in the DebConf local information page, is the Hospital Militar. It's a strange sort of thing as an American who remembers the 1980s to be seeking medical care from a facility operated by the Nicaraguan military; but accompanied by Fitoria, my native escort from the local team I had nothing to worry about; and besides, as a frequent international traveler I long ago learned the secret truth that people are people everywhere, no matter what flag they were born under. The highlight of the hospital visit was definitely when a member of the hospital staff, in full military uniform, shooed me towards a chair instead of standing to talk to her because "every patient has the right to sit, no matter what country they're in". After six x-rays and a doctor's consult, the conclusion was that it's probably not a broken bone and that it will probably clear up in just a couple of days with an even-better anti-inflammatory prescription and taking care of it by not walking on it. And indeed, my foot was already feeling better by Friday and aside from a little tenderness is now just about 100%. There are plenty of other entries on Planet Debian talking about the conference itself, and I don't think I have much to add to what's already been said there. But as for Nicaragua, I can conclude that it must be one of the best countries in the world to break your foot in - between the help of the hotel staff, the top-notch medical professionals, and above all the support of the DebConf local team (with a very big thank you again to Fitoria!), this is one brand of socialized medicine I can appreciate.

What do you think?

Not sure if that will work as I expect, but here as my runs in the city of Managua, combined in one single map, thanks to OpenRunner: <script src="http://www.openrunner.com/orservice/inorser-script.php?key=mykey&amp;ser=S03&amp;id=1802807&amp;w=500&amp;h=350&amp;hp=128&amp;k=5&amp;m=0&amp;pa=0&amp;c=0&amp;ts=1342329989" type="text/javascript"></script>

One of the features that I have been asked for multiple times is the ability to use control@bugs.debian.org commands at submit@bugs.debian.org time. I have now implemented this with the following syntax:

Package: foo
Version: 1.0-3
Control: retitle -1 this is the title
Control: severity -1 bleargh
Control: summary -1 0
Control: forward -1 http://bugs.debian.org/nnn

In short, you preface any control commands with Control:, -1 is the current bug, and the rest of each line is the control@ grammar you already know. This also now works for every kind of message to nnn@bugs.debian.org with the exception of messages received at nnn-done and nnn-forwarded. I don't know why you'd use it for anything else but submit@ messages, but hey, whatever works.

Here's what I found out during the "Packaging with git" talk at Debconf12. There are certainly cool enhancements. Feel free to share on Planet.

bubulle@sesostris:~ $ cat .bashrc
# http://lukasrieder.com/2009/07/14/extend-your-bash-ps1.html
parse_git_branch()  
  git branch 2> /dev/null   sed -e '/^[^*]/d' -e 's/* \(.*\)/(\1)/'
 
# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color xterm screen)
    PS1='$ debian_chroot:+($debian_chroot) \[\033[01;32m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\[\033[01;33m\]$(parse_git_branch)\[\033[00m\] \$ '
    ;;
*)
    PS1='$ debian_chroot:+($debian_chroot) \u@\h:\w$(parse_git_branch)\$ '
    ;;
esac

Neil McGovern asked me to add an additional feature to the BTS to support tracking the current status of attempts at fixing a bug. In past releases, we've used the nice commenting feature of bts.turmzimmer.net to keep track of what is going on in a particular nasty RC bug, who is working on it, and what needs to be done next (or if everyone can just ignore the bug). This feature should probably have already been in the BTS to start with, but now it is. In addition to the existing summary feature, where you can nominate a message or text to be the summary for a bug, there is an outlook command, which tracks the current status of the bug, and behaves in exactly the same way:

outlook 12345 not good
outlook 54321 0
thanks
I'm totally stymied by #54321.

for example. I plan to include the outlook in the bugscan output in the future too, so it'll be easily accessible. (And possibly up-to-the-minute with some javascript-fu.)

After attending several talks and BOFs at Debconf12, I'll grant my personal "Best Talk Award" to Hideki Yamane's Let's shrink Debian package archive!. Despite it being his first ever Debconf talk/BOF, Yamane-san did an incredibly complete research work to bring arguments about ways to reduce the size of the archive by using xz compression. He triggerred a very live discussion (and for this we can also thank all participants) and the quality of his slides was really high. So, for this, as Tom Marble said after the talk. You definitely deserve it and I'm proud to have you as teammate in the pkg-fonts team.

As already written, even though it seems, I didn't spend my time running at Debconf12. Or eating cheese... Or (tentatively) hiking volcanoes... Or helping people to kill each other with socks... Or drinking beers... Not *only* all of these (some of them at the same time, though hiking a volcano while eating cheese and drinking beers is not particularly easy)....but also some Debian work. So, I uploaded a backport of samba to squeeze backports and our squeeze users should now have the same samba version than wheezy ones. I also stopped several cronjobs on i18n.debian.net and moved some material there as links have been (or should be) moved to the brand new i18n.debian.org (and its alias l10n.debian.org). I did a major cleanup in tasksel, committed several fixes, proposed others for review (mostly to Joey Hess). All this in preparation for a soon-to-come upload, probably after D-I beta1 which has been prepared by Cyril Brulebois while he was.....not attending Debconf12.. I also followed the integration of Sorina Sandu's work on netcfg for link detection and network ESSID choice in Debian Installer. Sorina is doing well in her GSOC work, because she's clearly someone with great capabilities who we will, I hope, be able to keep contributing to Debian. We can also thank the mentoring work of Gaudenz Steinlin to guide Sorina through D-I's arcanes. I also went through the current status of debconf translation completeness in testing for the 7 languages that target 100% (Czech, German, Spanish, French, Portuguese, Russian, Swedish). Here, the point is mostly taking care that fixes are either:

• already fixed in unstable (therefore checking that unblock requests have been sent by maintainers)
• sent as a bug report (so that I can harrass package maintainers to fix it)
• under work by a localization team (so that I can pester them to move on)

I can we have good chances to achieve this goal for at least 6 of these 7 languages (Czech might be more tricky as several translations are not yet made). Finally, I also did most of my regular Debian work (which usually takes 1-2 hours every day)...and bits of my paid work (sorry for those people who I shared the table at breakfast, but that was my only common time window with my team at work). So, well, quite productive weeks, once again.

This morning, I ran again with No l, my longstanding Debian running friend. The goal was, this time, to explore the South-East heights of Managua. I noticed a road that seemed to be quiet enough and not requiring a too long transit through busy, noisy and bad smelling highways. So, at 06:00 we headed from the Seminole hotel to the road to Masaya (the very large highway that goes in front ofMetrocentro). We had to run along it for a bit less than 2km. Not the best thing but the road was not very busy at that time. Then, we turned right into a road heading towards a quite "classy" neighbourhood where roads are well paved, there are sidewalks, etc, etc. It was going up ALL TIME LONG, which is interesting as a start. This placed is named "Lomas de Santo Domingo" in Google Maps. We even found there the embassy of the Islamic Republic of Iran. I can tell you, the Iran ambassador is quite living in a neat place and probably very happy to be there..:-) Fromthere, a very good concrete road starts to go up and up and up and up. many many very high standard villas, with fences, guards, etc. Strangely, there were several "For Sale" signs instead of "Se Vende". So, I guess this is a sign that this place is mostly inhabited by (very rich) foreigners, diplomats, etc. This very nice road was also....climbing a lot: 180m in 3.5km, so 5.1% average, but sometimes closer to 10%! At the very end of the road, we however ended....on a fence. It's apparently guarding the final part of the road where even more fancier villas seem to be, according to the satellite view..:-). We tried to use a small path up, but had to stop quite quickly. (OK, No l is definitely blurry there....blame the tired eyes after 8.7km climbing all the way) And then, all we had to do was....going down..:-). Being both in a fairly good shape, that went quite fast. But we both agreed that the final part, above 12km/h along the highway, with the sun hitting hard, was quite a challenge. I really admire those people who happen to run long distance in places like Managua. I can't even imagine running a marathon here.... GPS trace of what finally turns out to be my longest run here as of now with 17.5km in about 1h40.

It s the last day of Debconf 12 in Managua, it s the first ever Decbonf I ve attended and it has been just awesome.

Attachment	Size
La mochila viajera, 13 de julio del 2012: Migrantes y software libre	84.19 MB

My terminal emulator of choice is xterm: it's fast, light, and (since it's pretty much the reference implementation) it has excellent support for everything a console user could desire... except for one thing that would be very, very convenient: making URLs clickable. Other terminal emulators have this feature, but they also have problems that make them inferior to xterm in different ways. Over the years people have come up with various workarounds for this situation, like screen scraping utilities (urlview, urlscan) that can be hooked up to other console programs to extract and browse URLs, but they're still not as convenient as just using the mouse, and often require the program to run on the same machine as the browser. Fortunately, xterm #277 (released in January 2012) added a new feature that provides almost exactly what I had been looking for: it can now spawn programs using the exec-formatted action and give them as argument the contents of the current selection or clipboard. So you can add the following to your ~/.Xresources: *VT100*translations: #override Meta <Btn1Up>: exec-formatted("x-www-browser '%t'", PRIMARY) which makes xterm run x-www-browser on the selection when it receives Alt + left click. (Adjust for whatever your Meta key is.) This is advantageously combined with a charClass setting to make xterm treat URLs as a single word, so that you can just double-click on them to select them: XTerm*charClass: 33:48,36-47:48,58-59:48,61:48,63-64:48,95:48,126:48 With both of these enabled, opening URLs is now just a matter of:

1. Double-clicking the URL to select it
2. Doing Alt + click anywhere on the xterm window to run the browser

which, while more involved than a single click, it still much faster than having to copy the URL manually to the browser.

Not few times I ve come upon the situation where I m working over a Subversion working copy locally and I wanted to commit bits of what I ve already baked and ready to go. Odds are that there s only one file not belonging to such changeset but mostly there are many files scattered around. This situation, I learned, can be managed with a lot more flexibility and fun.
svn changelist is a nice tool for such situation. svn changelist allows you to create a list of files I want to do something with meaning that you can use the changelist on your usual svn operations, read commit, remove, etc. Let s suppose you start with a project myapp, then you start creating three files A, B and C.
dragon% touch A B C
dragon% ls -lh
total 0
-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 A
-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 B
-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 C dragon% svn add A B C
A A
A B
A C
dragon% svn ci "first commit of A, B and C" .
Adding A
Adding B
Adding C
Transmitting file data ...
Committed revision 1.
Now we want to edit A and add few pieces of text. Then edit B also.
dragon% echo "This file looks empty, so let's put some text inside it" > A
dragon%
dragon% echo "I'm afraid this one also is empty. Just in case" >> B
Now, I need to work on this C file and that implies touching B also. I don t want to commit the changes I ve already made since I haven t made up my mind about them.
dragon% echo "C is a nice name for a source file, but this one doesn't look like one does it?" > C
dragon% echo "I'm going to add few lines to B too" >> B

dragon% svn st
M A
M B
M C
So, let s suppose I m ready to hit the key and commit the 2nd revision. But I m not done on A, so I want to commit just B and C the way they are now. Here svn changelist enters the arena. I can create a changelist for the two files and do several tasks related to them. Let s see.
dragon% svn changelist mylist B C
Path 'B' is now a member of changelist 'mylist'.
Path 'C' is now a member of changelist 'mylist'.
Now I have a changelist named mylist that I can do operations with. For instance,
dragon% svn st
M A --- Changelist 'mylist':
M B
M C

dragon% svn diff --changelist mylist
Index: B
===================================================================
--- B (revision 1)
+++ B (working copy)
@@ -0,0 +1,2 @@
+I'm afraid this one also is empty. Just in case
+I'm going to add few lines to B too
Index: C
===================================================================
--- C (revision 1)
+++ C (working copy)
@@ -0,0 +1 @@
+C is a nice name for a source file, but this one doesn't look like one does it?
Now let s commit the list.
dragon% svn ci -m "Comitting files from the mylist changelist" --changelist mylist
Sending B
Sending C
Transmitting file data ..
Committed revision 2.

dragon% svn st
M A
Now that I ve committed the files, the changelist mylist vanishes from our working copy. I cannot do any new operations with it. Few things you have to consider when using svn changelist.
changelist s are created in a one-time list, that means you cannot add another file to an existing list. If I type svn changelist mylist A it will define the changelist mylist to have just one member, A. It will not add A to the existing member files, B and C. Now, you are free to remove any file from an existing changelist using svn changelist mylist --remove B, for our previous example. That will make the changelist shrink to just have one element, C. You can also have as many changelists as you want, and member files can be associated to each one of them. Use case for that could be a diff over specific files. For this test project it almost makes no difference using this feature, but when you have lots of file sitting modified on your working copy, this feature will keep your hair on it s place, and maybe save the day. svn changelist is available since Subversion 1.5.

I should also sketch out the physical and virtual circuits at and between each PoP as well as the vast array of Virtual Machines provisioned on the hypervisors.

Paolo Bonzini noticed something a little awkward in the Linux kernel support code for Microsoft's HyperV virtualisation environment - specifically, that the magic constant passed through to the hypervisor was "0xB16B00B5", or, in English, "BIG BOOBS". It turns out that this isn't an exception - when the code was originally submitted it also contained "0x0B00B135". That one got removed when the Xen support code was ripped out.

At the most basic level it's just straightforward childish humour, and the use of vaguely-English strings in magic hex constants is hardly uncommon. But it's also specifically male childish humour. Puerile sniggering at breasts contributes to the continuing impression that software development is a boys club where girls aren't welcome. It's especially irritating in this case because Azure may depend on this constant, so changing it will break things.

So, full marks, Microsoft. You've managed to make the kernel more offensive to half the population and you've made it awkward for us to rectify it.

comments

drive #1 To add to the fun of being in Nicaragua, my laptop's solid state drive died the second day here. Seems this is the failure mode for a SSD, get a little slow, and then a switch flips and it stops accepting any writes, at all, becoming a read-only media. Never was there an indication of a problem in SMART etc. Did you know that Nicaragua has neither names for most roads, nor addresses? Rather than trying to shoehorn the directions to my hotel into the address fields of Amazon.com, I shipped the replacement SSD to home, and thought I'd limp along. drive #2 I destroyed my second drive one hour after getting it working. A borrowed USB flash drive, which seems to have melted under the unusual load while I was away at lunch. Perhaps putting an ext3 filesystem on it was a very bad idea, although I have successfully run other USB flash drives that way for years. Perhaps it was a cheap drive that only pretended to hold 32 gb. drive #3 For several days I happily used the third drive, a USB hard drive, as my temporary root filesystem. Until I destroyed it by knocking it off my bed. drive #4, #5 Now my netbook is running from a Debian Live USB key, with a second USB key for my customisations. So far I have not managed to destroy these, but there's still a day left in my trip..

A new neighbourhood to explore today: the South-West/West area. Indeed, my original plan was going towards Lagunas de Nejapa and Asososca. However, I now understood that such non urban areas in Managua are almost inaccessible. It sound like walking and hiking in the nature is not something that urban inhabitants of Managua do often. So, in short, these places are....just impossible to go to. Anyway, I wanted to see this, just in case. As a consequence, I ended heading westward from Hotel Seminole through Avenida Miguel Obando Y Bravo (the busy highway close to the hotel, where we boarded the Day Trip buses). Running along this one is not a bad thing as it is not that busy, particularly at 05:45..:-) After crossinb Pista de la Unan that goes north towards the lake, I went 200m east then headed north up to reach the very busy Pista Juan Pablo II (or Pista de la Resistencia). For those who went to the day trip, this is the highway we went through at the beginning of the journey to Leon. It sounds crazy to run along a busy highway but:

• it was not that busy at that time
• this is the only way to not get lost in the barrios as we'll see later on..:-)

I followed that one during about 4km until it ends facing a cone-style mountain, about 150m high (former volcano crater?) After that long run straight, I ended at a big crossing, where the highways go either north or south....but a small street continues westward and is apparently going around the Laguna de Nejapa, at least according to Google Maps. However, there is indeed, as too often here, a barrier (which OSM would have told me, indeed). Hence, disappointed, I only could go back to the busy streets. I however decided that I would NOT come through the same way but rather try to run in smaller streets. This is where the problem lies. Indeed, Managua "barrios" are not always connected by streets to the large and busy streets that surround them. This is mostly because several rivers run south to north, towards the lake. And these are canalyzed to avoid floodings, which means there are not that many bridges to cross them. So, it often ends that a barrio is only connected on one or two of its sides, which makes travelling through them particularly difficult and puzzling (especially going in the east-west directions). So, I happened to search my way many times in these places, particularly in Barrio Pablo Sexto where the rivers directions are really confusing..:-) I finally had no other choice than going down to the big Pista Juan Pablo II and come back the same way to the hotel. The final result is a 15km run in 1h20. Not that a bad pace in these weather conditions. GPS trace

Android vs iPad I m currently in discussions with a client about a potential future project which involves a tablet computer talking to some electronic equipment. The options are an Android tablet and an iPad. One advantage of Android is that it runs on devices of all shapes and sizes, so we can choose a device that fits the need rather than designing everything around the iPad. But the real problem with iPad is Apple. To run an app on an iPad you need to submit it to Apple, hopefully get it accepted into the App Market, then install it. This process causes some delay, a minor fee, and has the potential to derail the project if Apple doesn t accept the app on the first try. With Android there is no need to even deal with Google, the app can be installed directly without the Google Play store. I may end up working with an iPad (which admittedly is really nice hardware), but it seems most likely that the project in question will run on Android only. Windows vs Linux and Apple OS/X One of my clients recently paid a web development company to redevelop his web site. I turned out that the web developers in question only knew how to develop for Windows and my client didn t discover this until too late. Now a site that s currently using a small fraction of the resources on a $80 per month Linode instance will run on a Windows virtual server costing $300 per month (which includes SQL server license). The Windows virtual server will probably be managed (because my client uses only Apple and Linux systems and doesn t employ anyone with Windows skills) which adds an extra $100 per month. If the server isn t managed then they will have to hire someone to apply patches and that won t necessarily be cheaper. So using Windows is going to cost my client an extra $400 per month when compared to the possibility of running a Linux system on the existing virtual server. Even if my client had someone with Windows skills to run the server it would still be an extra $300 per month. If the NBN was available then my client could run a Windows server in their office, but it s not yet available in their area. Even for a company that employs people with more Windows skills than Linux skills there are still economic factors in favor of Linux due to smaller hardware requirements and the lack of license fees for all the core software (OS, database server, web server, etc). Summary These anecdotes aren t unusual, it s the sort of thing that happens all the time. Sometimes the result is good (EG avoiding the iPad), sometimes it isn t (being stuck with a proprietary web service). I think I ll have to suggest to my clients that every contract have a no proprietary software clause. Contracts can be amended if there is a reason, but it seems best to make a preemptive strike against companies that sneak proprietary software in and cause significant unexpected expense and difficulty. Related posts:

1. The Lenovo U1 Hybrid an example of how Proprietary OSs Suck Lenovo have announced their innovative new U1 Hybrid laptop [1]....
2. My Prediction for the iPhone I have previously written about how I refused an offer...
3. Liberty and Mobile Phones I own two mobile phones at the moment, I use...

For quite some time, I've suffered slow boot - it had useless 10 seconds delay while initializing SATA with SSD disk:

[    2.761669] ata1: SATA max UDMA/133 abar m2048@0xf2528000 port 0xf2528100 irq 44
[    8.118202] ata1: link is slow to respond, please be patient (ready=0)
[   12.764701] ata1: COMRESET failed (errno=-16)
[   13.084612] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

After some googling, I came to conclusion it is bug in SSD firmware and looked for update. Release notes documented some fixes to slow boot, what seemed to be related. The only issue was that the firmware update is available only as ISO image. And guess what I have no CDROM (actually I have no clue for what I would have used it). Fortunately the update is doable with just grub and syslinux. First, download ISO provided by Intel and extract eltorito boot image from it using geteltorito script and copy it to /boot/. Then get yourself syslinux and copy memdisk to /boot/. Now you just need to edit grub configuration to include following lines (you might need to adjust it according to your partition setup):

menuentry "SSD Update"  
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        linux16 /memdisk
        initrd16 /ssd-fw.img
 

Now you can reboot and choose SSD Update from the grub menu and perform update! After update the slowest part of boot process is me entering LUKS password, but I'm afraid this is not easily fixable :-). PS: The difference you can see after update:

[    2.797551] ata1: SATA max UDMA/133 abar m2048@0xf2528000 port 0xf2528100 irq 44
[    3.115694] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

Filed under: English Linux 0 comments Flattr this!

In the past I used to argue that accurate desktop DPI was important, since after all otherwise you could print out a 12 point font and hold up the sheet of paper to your monitor and it would be different. I later gave up on the idea that accurate DPI measurement was generally useful to the desktop, but there's still something seductively attractive about the idea that a 12 point font should be the same everywhere, and someone recently wrote about that. Like many seductively attractive ideas it's actually just trying to drug you and steal your kidneys, so here's why it's a bad plan.

Solutions solve problems. Before we judge whether a solution is worthwhile or not, we need to examine the problem that it's solving. "My 12pt font looks different depending on the DPI of my display" isn't a statement of a problem, it's a statement of fact. How do we turn it into a problem? "My 12pt font looks different depending on which display I'm using and so it's hard to judge what it'll look like on paper" is a problem. Way back in prehistory when Apple launched the original Mac, they defined 72dpi as their desktop standard because the original screen was approximately 72dpi. Write something on a Mac, print it and hold the paper up to the monitor and the text would be the same size. This sounds great! Except that (1) this is informative only if your monitor is the same distance away as your reader will be from the paper, and (2) even in the classic Mac period of the late 80s and early 90s, Mac monitors varied between 66 and 80dpi and so this was already untrue. It turns out that this isn't a real problem. It's arguably useful for designers to be able to scale their screen contents to match a sheet of paper the same distance away, but that's still not how they'll do most of their work. And it's certainly not an argument for enforcing this on the rest of the UI.

So "It'll look different on the screen and paper" isn't really a problem, and so that's not what this is a solution for. Let's find a different problem. Here's one - "I designed a UI that works fine on 100DPI displays but is almost unusable on 200DPI displays". This problem is a much better one to solve, because it actually affects real people rather than the dying breed who have to care about what things look like when turned into ink pasted onto bits of dead tree. And it sounds kind of like designing UIs to be resolution independent would be a great solution to this. Instead of drawing a rectangle that's 100 pixels wide, let me draw one that's one inch wide. That way it'll look identical on 100dpi and 200dpi systems, and now I can celebrate with three lines of coke and wake up with $5,000 of coffee table made out of recycled cinema posters or whatever it is that designers do these days. A huge pile of money from Google will be turning up any day now.

Stop. Do not believe this.

Websites have been the new hotness for a while now, so let's apply this to them. Let's imagine a world in which the New York Times produced an electronic version in the form of a website, and let's imagine that people viewed this website on both desktops and phones. In this world the website indicates that content should be displayed in a 12pt font, and that both the desktop and phone software stacks render this to an identical size, and as such the site would look identical if the desktop's monitor and the phone were the same distance away from me.

The flaw in this should be obvious. If I'm reading something on my phone then the screen is a great deal closer to me than my desktop's monitor usually is. If the fonts are rendered identically on both then the text on my phone will seem unnecessarily large and I won't get to see as much content. I'll end up zooming out and now your UI is smaller than you expected it to be, and if your design philosophy was based on the assumption that the UI would be identical on all displays then there's probably now a bunch of interface that's too small for me to interact with. Congratulations. I hate you.

So "Let's make our fonts the same size everywhere" doesn't solve the problem, because you still need to be aware of how different devices types are used differently and ensure that your UI works on all of them. But hey, we could special case that - let's have different device classes and provide different default font sizes for each of them. We'll render in 12pt on desktops and 7pt on phones. Happy now?

Not really, because it still makes this basic assumption that people want their UI to look identical across different machines with different DPI. Some people do buy high-DPI devices because they want their fonts to look nicer, and the approach Apple have taken with the Retina Macbook Pro is clearly designed to cater to that group. But other people buy high-DPI devices because they want to be able to use smaller fonts and still have them be legible, and they'll get annoyed if all their applications just make the UI larger to compensate for their increased DPI. And let's not forget the problem of wildly differing displays on the same hardware. If I have a window displaying a 12pt font on my internal display and then drag that window to an attached projector, what size should that font be? If you say 12pt then I really hope that this is an accurate representation of your life, because I suspect most people have trouble reading a screen of 12pt text from the back of an auditorium.

That covers why I think this approach is wrong. But how about why it's dangerous? Once you start designing with the knowledge that your UI will look the same everywhere, you start enforcing that assumption in your design. 12pt text will look the same everywhere, so there's no need to support other font sizes. And just like that you've set us even further back in terms of accessibility support, because anyone who actually needs to make the text bigger only gets to do so if they also make all of your other UI elements bigger. Full marks. Dismissed.

The only problem "A 12pt font should be the same everywhere" solves is "A 12pt font isn't always the same size". The problem people assume it solves is "It's difficult to design a UI that is appropriate regardless of display DPI", and it really doesn't. Computers aren't sheets of paper, and a real solution to the DPI problem needs to be based on concepts more advanced than one dating back to the invention of the printing press. Address the problem, not your assumption of what the problem is.

comments