Uncarved

The mayoral election season is drawing upon New York City, and it’s time for the candidates to start taking on the causes that will define their election platforms. One of the issues that incumbent mayor Michael Bloomberg is starting to get vocal about a plan to implement MTA reforms, which his campaign website describes as:

A thoughtful, comprehensive 33-part plan that lays out tangible, realistic ideas to help the MTA reduce costs, reduce congestion, speed commutes, improve efficiency, enhance accessibility, and ultimately produce a safer, faster, cleaner, better mass transit system.

As a man whose daily routine has depended heavily on the operations of the MTA (particularly the subway system) for over a decade, this is a concern in which I’ve become heavily invested. I’ve encountered my share of frustrations with the organization’s results, and I frankly have much to say about ways to improve the overall quality of the MTA’s service.

To be sure, I have a number of specific thoughts about various points in this plan, but I’d like to focus on one particular point for the moment: the idea of turning 311 into they city’s “Mass Transit Hotline.”

I’m sorry — a hotline?

The stated goal of this hotline is to provide quick and easy access to transit information, such as service schedules, travel maps, and up-to-date alerts regarding planned and circumstantial service alterations. Indeed this is an important goal, but a phone hotline is honestly probably the one of the least effective possible ways I can think of to accomplish this goal.

Simply put, nobody likes to call in for “phone support” for anything. This is because phone support systems universally suck, for everyone involved.

Now, I do feel like it would be useful to also offer 311 as a source of travel information, but only for people who cannot get it by other means. It could be a valuable new offering for, say, the visually impaired. Or, as a last resort for a person in some other extenuating circumstance. As such, a transit hotline would be more of an accessibility enhancement for transit information.

The fact is there are already a number of ways to access timely transit information that are better and more effective than a call-in hotline. Unfortunately, the average MTA customer has no idea any of them exist.

One example is www.MyMtaAlerts.com. The tool allows registered users to subscribe to service alerts for information about specific subway lines, bus service, and more, which all get delivered to their email inbox, mobile phone, or both. Although there’s plenty of room for improvement, this tool does allow MTA customers to subscribe to important information about the specific parts of the MTA’s vast transportation system that is directly relevant to them, and gets the information into customers’ hands without the customers having to even think about asking after it.

Other tools, including a trip planner, schedule listings, and more, are also available at www.mta.info… provided you actually manage to discover them in the train wreck of a website (yea, I’ll confess: pun fully intended).

The fact that these do exist, however, demonstrates that the MTA is tracking and managing all this information digitally.

So the bottom line here is that, if Bloomberg wishes to make a meaningful difference in getting transit information into the hands of New Yorkers, he’ll have to focus on making this data more accessible.

This broadly boils down to taking the following actions:

1. Raise public awareness. Promote use of the existing tools in subway PA announcements. Rather than just reminding people that police may randomly search everyone’s bags, or discouraging people from giving money to panhandlers, or to step back from the yellow safety lines as trains enter and leave stations, these messages can encourage people to sign up for email and text message alerts online. Print subway ads. Run TV spots. Feature these tools prominently on MetroCards. This can begin immediately.

2. Redesign the MTA website. I don’t simply mean tweaking the colors, adding some gradients, and moving to some three-column layout. This site is in dire need of a ground-up rethinking of how it’s organized. Although I have loads of specific criticisms about this site, I’ll save those for a later post. For now, I’ll simply say that the home page needs, at minimum, to directly expose their existing travel tools. This can be pulled off iteratively, over the course of several months.

3. Expose the transit information via data feeds and Web Service APIs. The MTA is clearly tracking service information digitally, as it’s using it to power both the MyMtaAlerts website, as well as Google Maps’ capability to offer door-to-door travel directions via the MTA’s network. Connecting the infrastructure powering these services to data feeds and web services can allow both the MTA and third party developers to create new web and mobile device applications, designed to meet their customers’ evolving needs. This effort will take the longest of all, but will prove to be an investment that will have created a foundation for continued improvements for MTA customer service.

Having 311 take on the role of “Mass Transit Hotline” in an effort to get New Yorkers timely transit information is an idea would have, quite frankly, been deficient even in the 20th century.

But it’s 2009 now.

Bloomberg and NYC need to look to where government and society are moving. Mobile and web are the only information delivery solutions that can improve today’s commutes, while investing in improving tomorrow’s.

Government 2.0, Public Brainstorm Michael Bloomberg, MTA, NYC, politics

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.

Business Sense, Conversation Apple, Google, Google Voice, iPhone, iPhone app

Take this sucker with huge grains of salt.

Not sure how I’d feel about each app having its own keyboard, but who’s to say which details would make it into the shipping version, and which not?

Check it out Apple, rumor, video

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…

Modernizing Education, Public Brainstorm Android, education

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.

Tutorials bizarro, css, howto, humor