dretblog

Adobe Acrobat Accessibility

visiting http://acrobat.com/ with mobile safari is a special experience, one that very few companies provide to potential customers: the site tells you that you are using an unsupported browser, and urges you to upgrade to a supported browser. which is especially funny on the iPhone, because that essentially asks you to upgrade to a supported phone.

clicking the supported browsers link is interesting, too, because it takes you to a page listing the system requirements for acrobat.com. and of course what they need is not actually acrobat (i.e., PDF) support but flash, because adobe pages — big surprise here — tend to be very flash-centric. given that i only wanted to look up information about acrobat products on the iPhone (where PDF is actually supported), i found it particularly strange to be greeted by such an unwelcoming page.

another facet i really liked about the page is how it sports an accessibility link while at the same time being the prime example of how to not be accessible on the web (zero fallback information about the actual site). adding another nice touch, the accessibility link leads to the same unsupported browser page, so unfortunately accessibility information is only accessible to those blessed with a supported browser (it looks like adobe refuses to deliver its actually HTML-based accessibility page to mobile safari). what's most interesting about this is that adobe aficionados always point out that it is possible to create accessible content with flash or PDF, and in theory this indeed is the case. but if adobe itself does not care enough to actually do it, or maybe tried and was unsuccessful, then this tells us a fair bit about the real-world accessibility potential of those technologies.

JPEG Rotation and EXIF Information

one of the main reasons to get a new iPhone was to finally get one that has a non-ridiculous camera. the original iPhone camera was laughably bad even when the iPhone was released, and after three years, it had become something you'd expect as a free giveaway in a cereal box, not in an expensive smartphone. so i gave in and got a iPhone 4, and the camera indeed is quite nice. but now that i make decent pictures again, i recognized that they are not properly rotated anymore when you send them by email. it turns out his is a nice example of compatibility issues, and how they materialize.

first the explanation: older iPhones (or maybe it's the fault of iOS 4? i don't know and it does not really matter) actually rotated the JPEG before attaching it to the message, and they did so based on the accelerometer information embedded in the image that specified the orientation of the camera when the picture was taken (the actual image is always stored in the same landscape orientation). the information from the accelerometer is stored in the orientation field of the Exchangeable Image File Format (EXIF) metadata that is embedded in the JPEG file. the orientation field can have one of eight (yes: eight) values. it turns out that what happens now is that the iPhone does not rotate the image anymore, instead it expects the recipient to understand and support the orientation information and rotate the image accordingly. which means that depending on the mail program the recipient is using, the images may be correctly rotated, or not.

in terms of compatibility, this means that the approach has shifted from supporting all JPEG-aware clients (rotating done by the client) to only supporting EXIF-aware clients (if you don't know when to rotate, it's your problem). i have no statistics about EXIF support in mail clients, but i am sure apple's clients supports EXIF orientation. thunderbird doesn't support it, though, whereas GMail supports it, so there is a mix of support in major clients. being friendly to all JPEG clients and not just to EXIF-aware clients would be nice, so is there anything that would be lost by sticking with the previous aproach of client-side rotation?

with EXIF orientation, the image contains the information of the device orientation in relation to the actual JPEG image. this means that based on this information, it is for example possible to create statisticson how many pictures have been taken in which orientation. this information is lost when the client is rotating, because it then has to remove the orientation information to avoid that EXIF-aware clients are rotating the image a second time. my personal opinion is that EXIF is not actually a part of JPEG, and that it would be better to rotate client-side and be more robust. but i am pretty sure that apple has made sure that all its products are EXIF-aware, and thus in apple-land, everything is working well, and apple never cares a whole lot about how well things work outside of apple-land...

the new rotation handling has some other side-effects, too. for example, flickr does not support EXIF in email uploads, so users need to manually rotate after uploading. in this image, i have done that, but flickr in its infinite wisdom has decided to not rotate the original size image when rotating (don't get confused, it has been rotated now, read on), which means that the scaled down images are rotated, but the original upload isn't. this means you end up with differently oriented pictures in the different sizes made available by flickr, which is not very useful. but as it turns out, if you use flickr's picnik editor instead of the rotate command, and then rotate in picnik, it actually rotates all images (including the original upload), so until flickr fixes the rotate command (or even better, supports EXIF rotation when images are uploaded), it's a good idea to always rotate using picnik.

iPhone to Android: Make the Leap?

shamelessly copying the make the leap slogan from SRAM (which faced the prospect of entering a market where shimano seemed to be impossible to attack), this is my brief report of 30 days and 30 nights (another shamelessly copied tagline) of android usage. this test was made possible by google, which provided my mobile applications course with 30 free droid phones, each coming with 30 days of free service. thanks, google!

i have had an iPhone since its first release, and while i think that it is a very well-designed device, i dislike apple's strategic moves, so i went into the test with the goal to actually make the leap and eventually move to a more open platform.

i could stop this report right here because after only 10min, it became clear that android does not really work all that well when you're not a google user. i don't use GMail and thus was delighted to see support for POP and IMAP in a program called EMail. however, as it turns out, this program really is nothing else than a rebranded GMail program, which means it may have support for accessing POP/IMAP servers, but it is designed around interactions based on GMail's design: you can star messages (how does that map to POP/IMAP?), but you cannot move messages between folders. which means that was it for my desire to switch: there's no way i am going to switch to a platform that may have great GMail support, but has lousy email support.

this first experience also represents the rest of my experiences with android. it's very rough around the edges, and my main feeling is that it is probably good enough for anybody moving up from a feature phone, but disappointing for everybody who has been spoiled by the refinement and perfection of the iPhone platform. it reminded me a lot of experiencing Linux, which in theory works as well as windows or mac, but in practice it becomes very apparent that there is no centralized and final quality control; it just feels different from something that has been developed with actual quality control in place.

what i found strange is that the development of the platform itself still has the small startup vibe of the pre-acquisition days, instead of feeling like google really putting its development muscles behind it. for example, the android browser currently does not support animated GIFs, which is pretty remarkable given that this is a mid-90s technology. but what's more interesting is the general developer attitude shown in the official android bug report. it's basically the we'll get to it when we get to it attitude of a small team, instead of google recognizing that support for 15-year-old basic web technologies should maybe have some priority.

some things are really great on android: maps work better and with the labs feature, there even is the terrain view, which will probably never make it to the iPhone now that the google/apple love affair is officially over. navigation is very useful and seems to work very well. being able to display my maps is also promising, but i have to find a better way to manage geo content through my maps.

some functionality on the platform is good (maps), some is bad (email), but what's consistently not even getting close is the UI/UX design. things are routinely hidden behind the menu button, sometimes behind a second level of protection (a more button in the menu menu), and many interactions are more complicated than they would have to be. if somebody with little UI/UX background and experience routinely runs into things that look like i could have done that better, that's not a good sign for a platform.

so instead of literally giving away thousands of free android phones, i think google would be much better off putting 100 UI/UX designers on the android team and make them clean up the platform right now. if google is serious with challenging the iPhone platform, they have a lot of catching up to do, and looking at the last update (from 2.0 to 2.1), i don't even know what i got from that. the next version has to make a considerable step forward in UI/UX, or the most likely challenger of the iPhone might follow the path of WebOS.

oh, and, could you please include an email client in the next version? thanks!

Feed Theory and Facebook Reality

my original plan was to write a post about how to circumvent facebook's absurd limitation that users are only allowed to import exactly one feed into their accounts. this limitation is obviously fueled by facebook's desire to pull people into the platform instead of using the platform as a hub. my goal was to show how easy it is to engineer around this limitation because feeds are standardized and thus can be mixed and mashed.

after going through the steps of creating a feed from a variety of other feeds, facebook then rejected the feed claiming it was not actually a valid feed (which it was). but after some experiments with various settings and ways of nudging facebook into accepting the feed, they finally accepted it, which means that if the instructions here are not working the first time, try a couple of times and maybe then it works...

let's assume you have a variety of feeds you want to channel into facebook. in my case it's the blog you are currently reading and my flickr photostream. both sources have feeds (blog feed and flickr feed), so the question is how to combine those (and maybe more) into one feed that then can be fed into facebook.

as usual, the 900lb gorilla of the web has something for us: google reader. the process of combining feeds is not entirely obvious, but it is fairly easy. subscribe to the feeds you want to combine (no need to worry whether they are Atom or RSS feeds, google reader handles them equally well). then, in feed settings, add the ones you want to combine into one folder. when you're done with adding all the feeds you want to combine into one folder, go to manage subscriptions and folders and tags and make that folder public. that's it. now go to view public page of that folder and on that page you will find a link to the feed for that folder. this is the feed you have to import into facebook.

all of this, of course, makes all the data you're handling here entirely public, but it very likely has been public in the first place because it has been published in feeds somewhere. but feeding it into google makes it even more public, and you might want to think about this for a minute.

the final challenge is to find the place where to import that feed into facebook, and the most important thing to keep in mind is that in facebook lingo, feeds are notes. also, facebook will make it excruciatingly hard for people to find the link to the original post (it is possible to find it, but it is very well hidden), but at least now all of the feed goodness originating somewhere else can flow into facebook.

New Stimulus Report Scrape

we just updated our scraped data for stimulus reports, this comparison page shows the reports we scraped from recovery.gov as well as the reports we got from agency sites directly. we now have 416 reports we found on recovery.gov, and 92 reports we found at agency sites. but please keep in mind that finding agency feeds is not all that easy, so we might have missed some agency feeds that recently became available. it is also important to keep in mind that even though the february as well as the april OMB reporting guidelines specify that reporting has to be done via feeds, nobody seems to enforce this, and OMB itself is only accepting report from agencies via email, which kind of defeats the purpose of having feeds for the agencies.

it also is interesting to point out that there is a new template out there, version 1.4. we usually find out about this because our code crashes; some new template is encountered, and then we have to reverse-engineer the new structure and add this to the scraping/parsing/transformation process. the interesting thing about the new template is that it is the first time that there's some location data in the reporting, in this case in the form of a state code (here are examples in HTML and in XML, as well as the original Excel). this is probably not the granularity where things get exciting, but it is definitely a step in the right direction: get your map mashups ready!

with new guidance expected next week (and not this week as i originally thought), i am sure all of this will change again. and playing whack-an-excel with the changing data gets less exciting, now that we have a toolset in place. but this also shows how hard it still is to follow the data flow about stimulus spending, if you really want to have all the data (and ideally from the source, the agency feeds). publishing HTML/Excel on the web is only marginally open and not transparent at all, and even the recently added feeds do not help all that much, because they are neither paged nor archived. (well, our feeds are not paged as well, but at least they're complete, and we don't run on a $84 million budget.)

so we are definitely looking forward to next week's updated stimulus reporting guidance, and to a certain extent, we can probably judge the quality of the new guidance by how much easier it will make it for us to do what we have been doing so far. after all, all we are trying to do is to keep track of all of the reporting that is published somewhere, and so far, this job has required much more reverse-engineering and continued updating of code than it should.

REST Programming Toolbox Requirements

REST is all the rage, and everybody claims they're doing REST. REST is a style of designing web services, and the question is how this style can be best supported by a programming environment. there are two possible perspectives of this problem. one is the more high-level view of how to best structure code that is built around the assumption of a uniform interface. a popular example for this is JAX-RS, released as JSR-311 last year, and implemented by the Restlet framework. this is not what i want to discuss here.

a different perspective is that of basic tools that might be useful for implementing RESTful services (in that case interpreting REST in its narrower sense of web architecture and its use of HTTP and URIs). in a recent blog post, marc hadley reports on Integrating Jersey and Abdera. the interesting thing is how his approach combines a high-level framework (JAX-RS), with more low-level tools for handling HTTP and content (in that case, feeds).

so looking at the low-level support one would like to see when programming RESTful services, what is required or useful? i came up with this list, which is probably incomplete, so any feedback about what else should go in here would be highly welcome!

• HTTP support: HTTP must be fully accessible, which means that all methods, headers, and status codes must be accessible to the application. if required, certain behavior might be enabled on request (such as following redirects), but this should be fully under the control of the application.
• HTTP encoding: since content in HTTP can be transmitted using chunked encoding or some transfer-encoding, it must be possible to either explicitly deal with these encodings, or to have this handled by the HTTP API.
• HTTP authentication: in many cases, HTTP authentication is required for gaining authenticated access to access-controlled resources. the HTTP API should support the predefined HTTP authentication methods (basic/digest), and should also have a plug-in mechanism so that other authentication methods can be used as well.
• caching: caching is one of the core features of how REST can be optimized. caching can be based on modification dates and/or on ETags. client-side caches can be shared or private caches. there must be built-in support for caching, API controls for handling shared and private caches, and there should be integration with a client-side shared cache for the client as a whole (imagine how useful it would be if all browsers on your computer were smart enough to share the same cache).
• URI parser: URI parsing is not trivial, and URIs are used everywhere. there should be URI prcessing support for parsing and resolving URIs. and depending on where URI templates are going (they are still under construction), support for them  might be very useful as well.
• language tag processing: since language tags are part of HTTP and can be used in HTTP mechanisms such as content negotiation, handling language tags is a integral part of HTTP. since language tags have a surprisingly complex logic behind them, support for parsing and matching languages is very useful.
• MIME type processing: similarly to language tags, MIME types (officially called media types) have a structure, are used in content negotiation, and often should be compared or matched. support for these operations should be part of a toolbox as well.
• XML tools: XML is the most widely used syntax for machine-readable data, so there should be a parser, validation support for maybe various schema dialects (DTD, XSD RELAX NG), selection via XPath, hopefully XPath 2.0 as the more powerful language, and finally more advanced XML processing might be supported by XML-centric languages such as XSLT or XQuery.
• JSON tools: many RESTful services support JSON, and sometimes only JSON. support for parsing JSON therefore also should be part of the toolbox.
• Atom tools: one of the most widely used formats for machine-readable data is Atom, and thus Atom support should be part of the toolbox, also supporting additional features which are part of the Atom landscape such as feed paging.
• AtomPub: AtomPub is one way of implementing a RESTful service providing write access to Atom-oriented services, and thus support for AtomPub (at least for the client side) might be useful as well.
• fault-tolerant parsing: many RESTful services access resources from a variety of sources. support for fault-tolerant parsing of HTML and feeds (in any of the RSS variants and in Atom) makes it possible to implement more robust applications.

while i am sure that this list is incomplete, i am really interested to better figure out what it really takes to provide a useful REST programming toolbox. currently, i am mostly interested to figure out what would be of general interest to most/many RESTful service developers.

Atom's Future as a General-Purpose Format

subbu allamaraju recently raised the question of Atom as a General-Purpose Format, and showed one example (Google Code Search Data API) that looked like a not-so-great way of using Atom. in my comment on his blog, i agreed to his observation that this did not look all that great as far as Atom goes, but i also argued that it might still make sense to use Atom for such a scenario.

comparing Atom with HTML (not as formats, but as methods for information dissemination) can teach us a lot, in particular when looking at possible future developments for Atom. the Atom Landscape already shows some similarities to HTML, thanks to Atom's extension semantics. there are microformats (licenses and paging, for example), there is a lot of custom code only picked up by custom clients (such as subbu's Code Search Data API example), and some of the Atom on the Web is so badly crippled that it is utterly useless for plain Atom clients. that's exactly like the good old best viewed in Internet Explorer web pages.

however, while this might not be what we want to see, it may very well be what we need to see to make Atom as exciting as i think it will be. the web is what it is exactly because HTML is so bad. HTML is bad on many different levels and not good at anything in particular. but it's sufficient as a container for an astonishing number of things, and it is simple enough to be learned and used by many. people still use PDF when they care about display fidelity and Flash when they care about multimedia features, but all of these formats are nothing compared to HTML.

REST still is on its way up and i am concerned about the fact that it has been officially downgraded into a buzzword and will suffer the hype cycle backlash at some point in time. but regardless of that, REST is what makes the web tick, and for many people, REST is still hard to grasp (our WWW2009 From SOA to REST tutorial last week was great, but also showed us that there is quite some way to go to spread the message). having best practices and design patterns and frameworks and tools will help a lot, and i expect all of these to appear around Atom.

and we will see all the things that are inevitable when something gets picked up by many. we'll see under-specified extensions (such as GeoRSS), overlapping formats (such as Apple's Podcasts and Yahoo's Media RSS), toolkits (for example supporting feed paging and archiving), and all the other things (some of them invasive and/or malicious) we have seen in HTML. and as inconvenient as that may be from time to time, it also and most importantly is the sure sign of a healthy and active ecosystem.

so what does all of that mean for Atom-oriented developers? similar things as for HTML-oriented web designers, plus some extra care that's required because your goal is to be understood by machines, not by humans. always validate what you're producing, test with other than your preferred clients (such as a plain Atom feed reader), try to reuse established standards in the Atom Landscape or promising candidates for new formats, and most importantly: build your system in a way so that you can change and adapt. if new standards or formats emerge, you should be able to support them, because you have implemented a clear and clean separation between your model (whatever it may be) and the representation of it (Atom plus some extensions).

Finding Stimulus Agencies

starting from Finding Stimulus Feeds and figuring out that this requires Finding Stimulus Sites, we are now back to square one, so to speak, trying to just figure out how to start the search for sites, so that we can find the feeds. recovery.gov has a list of available recovery sites, but it is not machine-readable and suspiciously short.

we are currently trying to compile our own list of eligible agencies, which should, according to the guidelines, set up recovery sites at agency.gov/recovery. it would be great to get some expert opinions on which agencies are actually eligible and thus would have to set up web site and feeds, if they decide to spend stimulus money.

ironically, there also is no machine-readable list of government agencies we could find. usa.gov has an A-Z Index of U.S. Government Departments and Agencies, but there only is a choice of paged HTML or PDF. we assumed that this would be a good list to start with, so we scraped that list and turned it into XML (and here is an HTML version of it). this list contains 587 agencies and their home pages as listed on usa.gov; most of them are .gov sites, but there are also a number of others, such as .mil, .us, and .net.

the next step will be to ping all of them for recovery pages (at agency.gov/recovery) and then see whether they return something. but before we start doing that, it would be great to get some expert feedback on whether these 587 agencies are what we really should focus on, or whether the recovery act guidelines apply to a different set of agencies that includes some we haven't in our dataset.

Stimulus Feed #2

after finding what may have been Stimulus Feed #1, we now have found one more, so we simply called it #2 (which of course may be completely wrong). this second feed has been made available the Department of Justice (DOJ)'s recovery web site. in this case, the feed is advertised through feed autodiscovery, so it can be found automatically once you've found the web site (how to distinguish between various feeds, if there were more than one, is a different issue that needs to be addressed when thinking about Stimulus Feed Details).

the interesting observation is that this feed does things very differently (but still according to the guidelines). it is not in great shape, but the feed validator only reports two errors. more importantly, the only entry's atom:link points to a non-existing page (and does not have a @rel attribute), but if you fix the development link to a guessed production link, it actually works.

the problem is that the entry (and the web page) is plain HTML. the web page is actually XHTML but is included in the feed as escaped HTML, which just makes processing a bit harder than it would have to be. but since it is well-formed XML, it can be safely unescaped and parsed. the actual web page is almost valid XHTML, but that one minor error does not really makes things hard and can be safely ignored.

what makes things hard and almost useless (from the viewpoint of somebody interested in the information) is that the HTML has no semantic markup at all. here is the markup for one of the table rows (and the table header row is not marked as such and only contains textual headers):

<tr>
 <td valign="top">15</td>
 <td valign="top">0402</td>
 <td valign="top">OJP</td>
 <td valign="top"> $2,765,000,000 </td>
 <td valign="top"> $ </td>
 <td valign="top"> $</td>
 <td valign="top">1) The allocation for the Office for Victims of Crime Recovery Act Compensation and Assistance formula grant programs was finalized.</td>
 <td valign="top">1) OJP intends to post its formula grant solicitations/announcements between March 6 and March 9, 2009.</td>
</tr>

this markup makes it almost impossible to extract the information from that page. compared to Stimulus Feed #1, at least in this case no proprietary data format must be parsed, but apart from that, it is hard to imagine how to reliably parse this information for automatically extracting information from it.

Finding Stimulus Sites

recovery web sites are mandated by the Initial Implementing Guidance for the American Recovery and Reinvestment Act guidelines, and recovery.gov keeps track of these sites and currently makes them available in a list of agencies and a list of states (also available as a table). it seems that none of these lists are available in a machine-readable format, though, so the problem of Finding Stimulus Feeds already starts here, because it is impossible to write code keeping track of stimulus sites.

ideally, these lists of recovery sites should be available as feeds, so that subscribing to this feed would allow people to track new sites as they become available. at the very least, these lists should be available in some machine-readable format, so that it is possible to use this information for tracking how well agencies are doing in putting up these sites.

the National Science Foundation (NSF)'s recovery web site does even publish a feed (which may very well be Stimulus Feed #1), but the feed cannot be found by feed autodiscovery, which introduces yet another hurdle for tracking the information made available by agencies. just adding a line like this to the recovery page's head would remove this hurdle:

<link rel="alternate" type="application/atom+xml" title="Atom Feed for Weekly Updates" href="/recovery/weekly.atom" />

it is really exciting to be able to watch this ecosystem grow in real-time. on the other hand, this quick growth (which is only just beginning) also demonstrates that the sheer magnitude of the recovery act will very soon make it impossible to find and use any of this information reliably, if more detailed guidelines are not put in please pretty soon.