{"id":5009,"date":"2010-11-19T07:14:00","date_gmt":"2010-11-19T15:14:00","guid":{"rendered":"http:\/\/palblog.fxpal.com\/?p=5009"},"modified":"2010-11-18T21:56:52","modified_gmt":"2010-11-19T05:56:52","slug":"data-structures-are-for-programmers","status":"publish","type":"post","link":"https:\/\/blog.fxpal.net\/?p=5009","title":{"rendered":"Data structures are for programmers"},"content":{"rendered":"

I just read an interesting post<\/a> by David Karger about PIM, end-user programming, data publishing, and lots of other interesting HCI ideas. The premise is that purpose-built applications for PIM impose strict schemas on their users, making it difficult to adapt, repurpose, or integrate the data with other applications. The alternative is something like Evernote, that lumps everything into one bucket, access to which is mediated largely by search. The tradeoff, then, is between a relatively undifferentiated interface backed by search on one hand, and a large number of siloed applications with dedicated interfaces.<\/p>\n

David describes several systems (interfaces) his students built that leverage the Haystack framework for storing arbitrary data, and suggests that it’s possible to structure these data management tasks as authoring<\/em> problems rather than as programming<\/em>, thereby making flexible, extensible, customized interfaces more widely accessible.<\/span><\/p>\n

<\/span><\/p>\n

His vision, I believe, is still predicated on fairly sophisticated users because the authoring process that involves arbitrarily complex data may require comparable complexity in authoring decisions, even if procedural programming skills are not required. Managing this complexity well in the user interface, I believe, will still require traditional UI and interaction design skills, which most people won’t have the time or inclination to learn.<\/p>\n

Thus we aren’t likely to lose the dedicated applications. But data federation is a different issue.\u00a0Here we have two possibilities: customized application-specific indexing vs. a generic data store. \u00a0The iPhone, for example, implements search across disparate items such as contacts, documents, and applications from a single interface, even though the data are all managed by individual applications. These applications still suffer from the lack of flexibility of the underlying schema, but they do balance access with task-specific interfaces nicely.<\/span><\/p>\n

The other way to go is to use some generic data store (e.g., redis) to store all application data. With the barest minimum of data typing (this is a string, this is a date, etc.) it should be possible to build a generic search interface for any data. <\/span><\/p>\n

The problem, of course, is that rigid schemas imposed by different applications still remain. What can we do about that? One possible solution is the one espoused by David Karger, that involves authoring. Another possibility is to give up on semantics, and let people create simple structures (lists, tables, etc.) that can be used to do light-weight, ad hoc organization. Basically, most PIM applications can be supported by a stripped-down version of Excel, packaged to remove all the messy controls. You get all the flexibility of data access, few constraints about how data can be organized, and all of this can be stored in a generic way that is searchable and can be transformed in arbitrary ways. Oh yeah, and you can program it, too.<\/span><\/p>\n


\n<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

I just read an interesting post by David Karger about PIM, end-user programming, data publishing, and lots of other interesting HCI ideas. The premise is that purpose-built applications for PIM impose strict schemas on their users, making it difficult to adapt, repurpose, or integrate the data with other applications. The alternative is something like Evernote, […]<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[24],"tags":[52,281,282],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/5009"}],"collection":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5009"}],"version-history":[{"count":3,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/5009\/revisions"}],"predecessor-version":[{"id":5011,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=\/wp\/v2\/posts\/5009\/revisions\/5011"}],"wp:attachment":[{"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5009"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=5009"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.fxpal.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=5009"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}