Yours and Mine: the NYC Data Mine

Thursday was a happy day for me. I was quite proud to learn yesterday that NYC has finally publicly demonstrated some evidence of tangible commitment to participating in the “open government” movement.

On 8 October 2009, NYC published a collection of open datasets in various machine-readable formats, from RSS feeds, spreadsheets, and more. These datasets are available at the NYC Data Mine. The NYC Data Mine is presently divided into two general types of datasets: the Geo Data Catalog, which offers “administrative and political boundaries, facilities and structures, and various imagery and base maps”; and the Raw Data Catalog, which offers all sorts of other types of data in the form of spreadsheets, RSS feeds, and various XML document formats.

Having browsed at what’s presently published in the NYC Data Mine, I must admit that — in its present state — I find the breadth of the offered data to be lacking. If this is the final state of things, it’d be lame compared — for example — to the data that the state of Utah has published.

That said, I’m willing to give NYC the benefit of the doubt here. Every effort has to start somewhere.

Moving forward, however, I’d still like to see the following:

  • A complete itemization of the City’s expenditures, down to the dime, including staff and office-holder payrolls.

  • NYC public school data, from student performance metrics to faculty information and budgetary expenditures to nutritional reports outlining what foods are served (and the serving volume) by each school.

  • Geo data showing property and business taxes collected by the City, perhaps down to the block level (I can anticipate concerns over privacy issues arising at any greater granularity).

  • Public heath care data, including frequency of reported ailments, injury, etc at each hospital, school, and other institution.

Note that, in all cases, data collection should err on the side of preserving anonymity, whenever there is reasonable concern that the data can be traced back to specific private citizens (especially with respect to specific individuals’ health and educational situations).

But the announcement of NYC’s Data Mine is only part of the story.

The City also launched NYC BigApps, a competition intended to raise awareness of this new open dataset, and to promote its use to create new tools to serve New Yorker City residents, businesses, and visitors.

From Mayor Bloomberg’s introductory post on the competition site’s blog:

NYC BigApps provides a competitive outlet for developers and encourages the general public to get involved as well. We welcome public comment on the process — indicate your support for the competition, share app ideas, and inform contestants on what type of app you’d like to see.

Ultimately it’s great to finally see NYC — my city — step up to the plate on the open government scene. There’s yet a long (long) way to go, but yesterday’s announcements do give me a glimmer of hope.

So — anyone up for a hackathon weekend… or three?

Tagging Friends in Facebook Status Updates

I recently discovered a handy little Facebook feature which allows you to tag friends (and Pages) in wall posts. It lets your audience know exactly who you’re shouting out (or talking smack) to. So I threw together a quick video introduction to how to use it.

As you can see, it’s quite simple and straight-forward to use. The tweeters out there will recognize that this feature is modeled directly after Twitter’s “mention” functionality.

Happy tagging.

Playing Hard Means Risking the Occasional Foul

Michael Arrington of TechCrunch published a post Friday, titled The Truth: What’s Really Going On With Apple, Google, AT&T And The FCC. It is—in my opinion—a fairly insightful piece, particularly regarding his analysis of Apple’s seemingly misleading wording behind their reasons for “not approving” the Google Voice app for inclusion in the App Store.

I do believe that Apple perceives a risk behind allowing this particular piece of software “hijack,” as it were, the iPhone user experience, particularly as the Google Voice service will likely become wildly popular amongst the demographic of folks who are attracted to products like iPhones. I must also note that Apple themselves pulled quite a similar customer “hijacking” trick on AT&T with the iPhone.

So if anyone knows the smell of this type of usurpation, it’s Apple. They’re also right to fear it.

I ultimately get exactly why Apple attempted to block it: to paraphrase the late father of a past girlfriend of mine, if you’re not pulling at least one foul per game, you’re just not playing hard enough.

It’s all a game of strategy, folks, and the stakes in the competition for slices of the burgeoning mobile Internet device market are pretty damned high.

Arrington does make one claim, however, that I just can’t get behind. He writes:

[Apple is] jealously guarding control of their users and trying to block Google and other third party developers at every turn from getting their superior applications in front those users.

The first half is spot-on, but the second half is very wrong—they are not fearful of developers offering better software than their apps. Apple doesn’t care, for example, about superior stock tracking, weather, or memo programs.

They _do_ care about Safari, Phone, Contacts, Calendar, Mail, Messages, and iPod, App Store, and iTunes applications: they are the signature apps of the core iPhone user experience.

If Google Voice takes over the dialer, a significant problem is introduced: people may likely start demanding that the phone experience is designed around the Google Voice service. In such a case, Apple will have lost control of the UX of this core component of the product, as they would then have to choose between two paths:

1. chase after the Google Voice UX requirements, OR
2. consciously choosing to ignore it, causing customers that want it evaluate switching to an Android phone.

Apple are specifically looking to control the core user experience of the device, but that’s what Apple does, and what’s more: that’s what we (largely) want them to do! Their passion for that sort of thing is directly attributable for the design excellence of their products.

In any case, the ref is on the field, and we’ll get a call on the game play. The only certainty here is that—whatever call the FCC ultimately makes—the outcome will be interesting.

My call: offensive holding.

Sketching the Migration to Digital Education

California governor Arnold Schwarzenegger’s recent proposal to adopt so-called e-textbooks for his state’s public school system has triggered a flurry of press coverage, as well as new products like the Kindle DX and CourseSmart‘s iPhone app in the market.

The idea has critics. There are concerns regarding the economic feasibility of the idea, as well as the intellectual property management, and naturally the functional requirements for such devices.

An overview of these matters includes the following:

  • Economic Feasibility

    1. How will the costs behind distributing the readers (the actual hardware units) to every student be covered?

    2. What business model(s) will be available for textbook publishers?

  • Intellectual Property

    1. What safeguards do publishers have against unauthorized distribution of their materials (eg, piracy)?

    2. What safeguards does the educational system have against vendor lock-in?– schools should never become beholden to any one company.

    3. What about ownership of the software itself? The operating system, the format of the interactive materials, etc.

  • Functional Requirements

    1. What sort of hardware capabilities must these devices offer? Of course, they’ll have to display text in layouts with photos and diagrams, but what about video? What about 3D rendering for visualization purposes, or network connectivity?

    2. What sorts of interactions must these devices allow students to conduct with the educational material? Will it support touch-based hyperlinking, annotations, or some sort of data sharing? What about end-of-chapter quizzing?

Clearly there are several matters that need to be thought through, but here’s a “sketch” for a potential solution.

Read More

Bizarro HowTo: Write CSS Like a Total Douche Bag

We’re half way through 2009. All the major browser vendors are shipping products with really great rendering engines now. Usage of the much-maligned Internet Explorer 6 has plummeted to the 15% neighborhood (stats vary, but they all show < 20%).

The days that Web developers dreamed about — seemingly, at the time, against all odds — for about half a decade are nigh upon us with this progression.

Although much work remains to be done before all browsers can be universally relied upon to render HTML in a consistent and relatively uniform manner, the Web development community can at least now begin breathing a sigh of relief about having finally gotten some of the worst of it behind us.

But has anyone ever stopped to think about the folks that actually get off on making other people’s jobs difficult? Clean style sheets? Progressive Enhancement? Semantic Web?

How do you suppose they feel right now? Whether it’s sadism or nostalgia, they’ve got feelings, too.

To them, I say with reassurance: fret not!

For them, I offer here three fabulous pointers for writing CSS like a total douche bag:

1. Use the same IDs for more than one element in an HTML document. The HTML spec is very explicit about not doing this, so you can absolutely bet that — some time down the line — some other developer tasked to add some jQuery or Prototype enhancements to your page will totally get screwed.

2. Sprinkle your IE 6 “hacks” directly into and all throughout your primary CSS files. Do not separate these IE 6 optimizations out from your main.css file into main_ie6.css. Coding your site to standards first will only make it easier to phase out this pollution when IE 6 finally drops off the planet. To ensure you really nail this one, you should be previewing the site in IE 6 from the very beginning of your development efforts. In fact, I could even recommend you develop the site’s HTML and CSS in IE 6 exclusively first, then go back and apply hacks to make it work in the rest of the more standards-compliant browsers… in fact Firefox 3.x and Safari 4.x both include really great developer tools to help you figure out which “standards compliancy hacks” you’ll need to use to keep the site from looking completely fucked in those browsers.

3. Use CSS style and ID names like next_alignright_blue or registration_form_gray. The more you mix styling cues directly into these names, the more you’ll be able to laugh and laugh and laugh and laugh when those “next” links need to be green when the site’s holiday theme feature gets finished after Thanksgiving. Honestly: what’s funnier than knowing that next_alignright_blue will render green links? And, if you’re truly lucky, maybe a usability audit of the site might conclude that the “next” links should not get jammed to the right, but should appear adjacent to their associated “previous” link.

4. Avoid descendant selectors like the plague. The only thing that these will ever afford you is the opportunity to minimize the number of IDs and class names. Where will your opportunity for laughs come when elements can be targeted by JavaScript enhancements using a syntax like this:

[#!javascript]
$('#sidebar .panel .description a.more').click( ... );

instead of:

[#!javascript]
$('#sidebar_videos_panel a.more').click( ... );
$('#sidebar_widgets_panel a.more').click( ... );
$('#sidebar_uploads_panel a.more').click( ... );
$('#sidebar_archives_panel a.more').click( ... );

The first example allows some other developer to continue to leverage the selector code to enhance the “more” link, should another .panel element with a qualifying like in its .body element, rather than having to explicitly add another line.

And so I hope I’ve demonstrated that there’s simply no reason to mindlessly progress into the hegemony of maintainability, efficiency, and sanity for your colleagues. Not when you can utilize simple little techniques like these.

With your efforts, we can squander much of this hard-earned potential for progress! If you have other douchey ideas you’d like to share, please leave them in comments.

A Single Pear

I’ve just invested several hours trying to get my system to use the Pear libraries from MacPorts rather than the Pear libraries I had installed years ago using the command line installer, as described here. This is largely because I’m happy to let the MacPorts package manager take care of upgrading my software, and making sure all inter-dependencies are looked after.

The command line installer adds files to the traditional /usr/local directory, while the MacPorts package manager adds the files to /opt/local.

And from there, troubles arose.

Read More

From a Dichotomy

Unix. It’s astonishingly flexible. This is, at different times, either wonderful or maddening. Sometimes even both at once.

Because of the flexibility it offers, there are several ways a particular enhancement or customization can be added to the system, and you are free to pick the one that best suits your needs or preference. The ensuing burden of this flexibility, however, becomes a responsibility on your end to mind just how you added each enhancement or customization, in case you later need to adjust it.

While you’re naturally free not to track such details, this practice guarantees that you’ll spend as much time trying to “re-figure-out” that clever enhancement or customization you figured out how to apply in your own special way.

History has taught me that any of these clever enhancements and customizations will eventually need revisiting. It’s inevitable… like destiny, except less romantic.

Read More

Gruber on Mobile Phone Keyboards

Gruber, writing about what he calls the Apple Way (emphasis added):

Are software touchscreen keyboards good for everyone? Certainly not. But this is another aspect of the Apple Way. Apple tries to make things that many people love, not things that all people like. The key is that they’re not afraid of the staunch criticism, and often outright derision, that comes with breaking conventions.

[…]

That the iPhone — or specifically its software touchscreen keyboard — does not appeal to everyone is not a problem. Nothing appeals to everyone. Even if you try to make something that appeals to everyone by adding every single clamored-for feature, you wind up with something like Windows that does not appeal to people with a taste for the elegant and refined.

And so Apple demonstrate mastery of yet another classic showmanship tactic: know your audience.