Author Archives: Jamie Forrest

The Next Phase is Not Web 3.0

Posted on by
Reply

O’Reilly Media’s Web 2.0 Summit, which took place over the last few days in San Francisco, got me thinking, why is the web still only in version 2.0?

Tim O’Reilly himself coined the phrase Web 2.0 back in 2004 for his first conference of the same name. It was defined by an evolution in front end technologies like AJAX and bubble letters, back-end technologies like web services and RSS feeds, and business models like crowdsourcing and software as a service.

So given that we’re 6 years in to Web 2.0, when will we get to Web 3.0? The answer is never. No one will ever start calling it Web 3.0. For one thing, it’s not catchy. Web 2.0 has a certain ring to it that Web 3.0 doesn’t. Also, I think it will be difficult for people to come to a consensus on when technologies have evolved enough to move to a new version number. Web 2.0 was coined by a single person. Web 3.0 would have to be more organic. We much more likely to describe future “versions” of the web in descriptive phrases rather than numbers.

Tim Berners-Lee has always been against this nomenclature anyway. His alternative to “Web 2.0″ was the “Read/Write Web,” because of the way in which users became empowered to contribute en masse to the data on the internet. And in 2006, when asked what Web 3.0 would be, he said that a component of it would be “The Semantic Web,” or “a web of data that can be processed directly and indirectly by machines.” In other words, a web in which the machines can glean meaning from the data, in addition to simply manipulating it.

But I would argue that we are already at the next evolution of the web, and yet it’s not about semantics. It’s about context. This new phase of the web has largely been catalyzed by two breakthroughs: advances in the power and reach of mobile computing, as well as what Mark Zuckerberg calls “the social graph.” Both of these lend not meaning but context to data, and that is a very powerful thing.

Mobile devices can contextualize data around locations, photos, video, and audio (among other things). And of course the social graph connects data to people. The “Internet of Things,” as it continues to grow, will increasingly connect data to objects (shall we call it the “object graph?”). Although context is a step in the direction of semantics, we are still a ways away from getting machines to the point where they can interpret meaning from this data.

Indeed the “web” isn’t even about machines anymore. What was once a network of machines connected by wires is now a network of people, places and things connected by context. There is a new network growing atop the old.

Perhaps the semantic web will come in version 4.0 (although we still won’t call it that). But I think the best characterization of the most recent evolution of the web is the “Contextual Web” (I am not the first to call it such). Twitter, Facebook, Foursquare, the iPhone, Android, and many other prominent technologies can fall under this term, and I think it best describes the current proliferation of mobile and social technology that is spawning so many new and interesting businesses.

read more from Jamie at jamieforrest.com

Minimizing Agony, Maximizing Pageviews

Posted on by
1

On Wednesday at the Launch Conference, travel search engine Hipmunk presented a new mobile version of their web app. But that’s not what I want to talk about. I want to talk about Hipmunk’s general approach to solving the problem of airfare search, and how it might be applied to other problems.

The genius of Hipmunk is in their “agony” algorithm, grounded in the key insight that when people search for airfares, price and departure time are rarely the only considerations. What people really want to know is how agonizing the trip will be, measured as a combination of price, duration, and number of layovers. So Hipmunk sorts your search results by this “agony” score (in descending order of course). Simple. Brilliant. There’s so much agony in the world; what else could this model be applied to?

The first thing that jumps to mind is turn-by-turn directions. Most navigation apps provide routes that optimize for distance or time, and in some cases by real-time traffic patterns. But there are a lot of other factors than can contribute to one’s agony while driving. For instance, given the choice, I’d much rather drive a scenic route than an interstate, but likely only if the scenic route isn’t orders of magnitude more time-consuming. Or maybe I’d like to drive a route with better food options than Shoney’s and Roy Rogers. Transit directions could also benefit from applying this model. I’d much rather take a trip that involved a transfer if the two subways were less crowded than the one, provided the trip duration wasn’t significantly longer.

Another great application of the “agony” model would be a site that helped you decide whether or not buy something online or at a nearby store. The algorithm could factor in a combination of item cost, shipping cost, shipping duration and return policy of the online option, and compare it to the item cost and travel distance to a local store that carries the item, as well as the real-time availability of that item in the store’s inventory (Milo.com is working on this last problem).

Sorting by “agony” factor is a powerful idea, and one that is quickly letting Hipmunk soar to the top of the travel search business. What other problems could you apply this model to?

read more from Jamie at jamieforrest.com

This Piece of Technical Writing Has Been Written By Me

Posted on by
1

In my role as a business analyst at Bootstrap I see a lot of technical writing, much of it terrible. For some reason, people whose job it is to be precise and logical often fail to do so when the language of expression is English, rather than Java. While the problems in technical writing are varied, the offense I most often see is overuse of the passive voice.

For those who don’t remember their junior high school grammar, passive voice is a grammatical construct in which the object of a sentence is repositioned as its subject. “Tom throws the ball” is active voice, while “The ball is thrown by Tom” is passive. The use of passive voice in itself is not grammatically incorrect, but it often weakens the clarity of the writing by obscuring who or what is doing the action in the sentence.

Technical writing is a veritable breeding ground for passive voice proliferation, in many cases because the actors in technical writing are not tangible. The actors are software code, or systems, or networks. My phone today popped up an alert that said, “The server cannot be reached.” Who exactly is the one not reaching the server? Is it the phone? Is it the app I was running? Is it me?

But just as a writer would avoid passive voice in “normal” English prose, so too should a technical writer avoid it in his work. Phrasing technical ideas in the passive voice dampens the agency of the thing doing the action, making it seem unfamiliar and disembodied. Technology does things. To render technology in the passive voice is to distort its power to create change.

This is especially evident when technical writing refers to error conditions, as in the case of the alert above. It’s almost as if the authors of the software were deflecting blame away from themselves with the message, “The server cannot be reached.” They could just as easily have said, “It’s not our fault that you can’t access this page. Talk to the dudes who run the server.” (People in IT love to blame the other guy, but that’s a story for a different post.)

It’s never that difficult to clean up language like this in one’s technical writing, but it often requires ascribing some degree of agency to to the technology. Instead of “The server cannot be reached,” one could write it as, “The application failed to reach the server,” or, “The application failed to connect to the server.” If English had a better indefinite subject pronoun, we could even write something like, “One cannot reach the server at this time.”

There are any number of solutions to the problem of passive voice in technical writing. The main thing is to be aware of the easy pitfall, and to think about technology more as an agent of change than as some hidden force behind the things we observe.

read more from Jamie at jamieforrest.com

Notifications, Unread Items and Information Overload

Posted on by
Reply

Last week I wrote about the strategies Quora.com employs to engage its users and keep them coming back to the site time and again. A big component of their strategy are notifications–the email and on-screen alerts the application uses to let you know that your attention is needed. Their notifications are tactful and largely welcome.

Unfortunately, however, like many other tools in the software architect’s chest, notifications can quickly cause insane levels of information overload when they’re used without careful thought.

Take for instance the Facebook iPhone app. Every time I open it and navigate to the main menu screen, I have some notifications waiting for me (usually people commenting on one of my wall posts or something similar). I’m alerted to this fact by a little bar on the bottom of the screen highlighted in a different color. This much I’m okay with.

However, if I then choose to close the app at this point without explicitly viewing the notifications, the app icon now has a little red number superimposed on it, telling me how many notifications I didn’t check. If you’re anal like me, this is torture. I now have to go back into the app and view the notifications in order to get rid of that annoying little red number.

“Unread” counts in email and news readers like Google Reader are another good example. Again, because of my mild OCD, I never let my inbox contain any unread messages. I even click on messages I know to be spam just so that they don’t keep notifying me of their unread status. Same goes for Google Reader. If I’m too busy to read everything and I have to skip some articles, I still have to mark them as unread so I don’t have to see that notification anymore. I’ve often thought that these applications should archive (or mark as read) any unread messages automatically after a certain amount of time goes by. If I haven’t read an email in 30 days, I’m probably not ever going to read it.

All of this information desperately begging for our attention leads to apathy at best and resentment at worst. It’s like the boy who cried wolf. Eventually we’re just going to tune it out.

I think the trick here is to think like the user before implementing things like this. Do I really want to receive more than one or two emails per day from a given application? Should notifications be persistent, or should they fade away over time? Should they be mandatory, requiring the user to take a certain action so that they go away? Or should they merely be indicative of an action that is optional? Should the notifications be opt-in or opt-out?

These are crucial decisions to make when creating software, decisions that could lead either to delight or disgust.

Jamie Forrest
Project Manager & Business Analyst

Generalization vs. Specialization

Posted on by
1

One of the more difficult tasks in software design is striking a balance between creating a general solution and a more specific one. Should we build something that can handle all sorts of hypothetical future requirements or one that solves a specific problem, but may not work for anything else down the road? Should we take longer and spend more up front but reap dividends down the road? Or should we go quick and dirty now and “cross that bridge when we get to it?”
For example, suppose you were building a web app that facilitated introductions over email. Jane wants to introduce John and Tom. Jane visits a website and enters John and Tom’s emails into a form. The application then sends emails to John and Tom saying that Jane would like to introduce them. John and Tom can click on a link in the email to confirm they would like to be introduced, and the application sends the two of them one another’s email addresses.

Thinking about the data model for this application, you reason that there should be a table that stores each introduction, with fields for Jane, John and Tom’s email addresses. But what if, down the road, you might want the application to support introductions for arbitrary numbers of people, rather than just two? Or what if you may want to handle not just email addresses, but phone numbers, mailing addresses, etc. Should you build the data model now to support these potential features, or should you wait until you need them to implement them?

On the positive side, building a robust data model now would enable you to quickly and easily build new features later; on the negative side, if, for lack of demand, you end up never implementing those features, well then you’ve wasted your time. On the other hand if you only build those things you need right now, over time you will end up with a tangle of spaghetti code.
So what’s the answer? Well, like many other things in life, it depends. It is really a case by case question, and that’s what makes it difficult. There are a few factors to weigh in making this decision:

* What’s the real likelihood of implementing this feature down the road? In the example above I would argue that introducing more than two people to one another at a time is a corner case and therefore not a likely future feature. On the other hand supporting phone numbers and mailing address has a high likelihood.

* What’s the cost of generalizing now? If the present cost of generalizing is just way too high (either in time or money), then you have no choice but to put it off for later.

* Have we been here before? If you find yourself designing something that’s eerily similar to something you’ve done before, and you can foresee having to do it again, you should take the time to generalize now.

I find that many good software engineers fall into the trap of over-generalizing, because that is what they were taught to do in college, and so everything they do just ends up taking forever. On the flip-side, bad coders never plan for the future and just keep heaping crap on top of crap as they go. So keep in mind the guidelines above next time you have to make this trade-off. And also keep in mind that this trade-off is happening all the time in software design, so if you’re not thinking about it, you’re either wasting money or building crummy code.

Jamie Forrest
Project Manager

….On the Importance of Requirements Gathering

Posted on by
2

You just purchased an empty 5-acre lot on a serene, wooded lake in upstate New York. You’ve been saving up for your dream vacation home, and the time has finally come to look for someone to build it for you. You narrow your search down to two construction companies; let’s call them Moe’s Mansions and Bootstrap Home Builders.

The account manager from Moe’s tells you he can build you an amazingly beautiful house, one that will be designed as it is built so that he can be sure to satisfy your needs at every step of the way. Why waste time designing everything upfront when you can just dig in right away, get your hands dirty, and build it quickly and with utmost agility? He says you’ll begin by defining the size and shape of the living room, and once that’s built you will continue to add on rooms until eventually you have a whole house. This is the best way to do it, he says, because you may not know what all your needs will be in advance, and as you see the house take shape, your needs may change.

The account manager from Bootstrap tells you he too can build you an amazingly beautiful house, but unlike Moe’s, Bootstrap says they will lead you through a detailed discovery and design phase, one that will attempt to flesh out your needs before one speck of dirt is cleared for the foundation. Bootstrap will clearly document all your requirements, and their architects will then draw up expert plans that the builders will use to guide their process.

Well, faced with these two options, of course you’d choose Moe’s right? Why would you waste money paying for an upfront design phase when you could just get started today with the actual building? And yet, how many houses can you think of that have been built without plans, without detailed architecural designs drafted by a skilled professional trained to elicit your requirements and translate those into instructions the builders can follow? It would be absurd to build a house the Moe’s way.

You would end up with a patchwork quilt of a home, whose later additions better reflected your desires than the first rooms you built. And what happens when you find out in order to build a second floor, you need to completely redesign your first floor to support that? Or what happens when you find out well into the building process that building a patio is going to cost three times as much as you had expected, and will take five times as long? Or worse still, what happens when Moe says he doesn’t even know how to build that screened-in porch you’ve always wanted. Woops.

At Bootstrap Software, we architect solutions custom-suited to your business needs and goals. In our discovery and design process, which takes place before developers write even a single line of code, we work systematically with our clients to examine and document the rules, workflows and idiosynracies of their businesses. Many people balk at the idea of spending time and money upfront to archictect a solution up front, but when you’re building complex systems that may require numerous points of integration with other systems both internal and external, it is the only way to go. Otherwise you end up with Frankensoftware.

Agile programming (Moe’s way) does have a place if 1) for circumstantial reasons you cannot elicit the requirements until you have something up and running 2) you are willing to pay (in time and $) for a functioning prototype to be built that may have to be rebuilt or re-factored.  We also understand that requirements may shift once an app begins to take shape (like deciding a granite countertop will work better than formica once you have seen the feel of the kitchen).  We mitigate this through our clickable wireframe / prototyping we do as part of discovery and design.  So if you are asking if we are “waterfall” or “agile” let’s just say we take the best of both worlds, customized to the project’s specific needs and bake an SDLC cake that serves the project.

Jamie Forrest
Project Manager