Archives

When a new browser comes out, like IE8, the verdict usually rolls in over the course of a few weeks as our QA testing on various web projects bumps up against its limitations. It’s too early for us to render a verdict, but the signs have not been good and continue to be negative.

The evidence continues to trickle in. Louis-Rémi Babé weighs in with his grim assessment:

• The JavaScript performance on IE8 is still lousy.
• Useful tags such as <canvas>, <svg>, <video> are still missing.
• CSS3 is minimally supported. (I agree that this is good news for web developers since we get to charge more money for all the extra effort that goes into IE8 work.)

To top it all off, Vector Markup Language (VML) is freshly broken. It’s one of those sad and frustrating stories. Read up on it here and feel sorry for all of those framework developers who have to crowbar in several hacks for all of the garbage in IE8.

Share/Bookmark

In the first installment, we covered the simple case, where your application is really a web app, not really using any device features, without local storage, just pulling data from a web application.  This time, we’ll tackle true native applications.

Share/Bookmark

Same Photo by Nick Atkins Photography

My cucumber obsession continues unabated. I’ve spent a lot of the last week adding Cucumber to projects, writing about it in a very long section for the Rails Test Prescriptions book, and generally trying to figure out how to use this tool, not to mention trying to figure out why this tool has been so interesting to me this week.

Some follow-up thoughts since last week’s post.

Share/Bookmark

A peek under the hood of google’s design apparatus.

In an interview with Newsweek magazine, Irene Au, User Experience Director at Google discusses her responsibilities, and in the process, reveals some telling things about the way design decisions are made at the multi-billion dollar internet company.  Perhaps not surprisingly, she makes it clear that Google takes a data driven approach to interface design just as it does to everything else.  The subjective opinions of art directors or visual designers don’t play a key role in the design of their products.  As she states, “A lot of our design decisions are really driven by cognitive psychology research that shows that, say, people online read black text against a white background much faster than white against black, or that sans serif fonts are more easily read than serif fonts online.”  No argument here.
But is a completely empirical approach to interface design desirable, or even realistic?  Isn’t it more likely that the left brain culture at google puts greater weight on the opinions of engineers, even if they are being just as subjective? One blog commenter put it this way, regarding Au’s interview with newsweek:

Share/Bookmark

Security is unlike other aspects of software in that it follows a steep value curve: either your system is secure, or it is not. Either it provides its full level of value, or it provides none at all. There is often a tendency to address security up front (even when other aspects of the system are built iteratively). What others sometimes fail to see is how this generates unneeded cost and complexity as the project matures.

Share/Bookmark

photo credit: foxypar4

If you’ve every seen professional golfers drive the ball up the fairways, or putt the ball on the greens, they make it seem so easy. But for the vast army of us duffers out there, we know it is anything but.

There are many variables to consider to ensure success on every hole you play. There’s the distance from the tee to the greens, the natural elements  — wind, rain and sun –, the number of allotted strokes per hole, the vexing choice among various woods and irons, the hazards dotting the course, and the mental and physical aspect of dealing with this humbling game. But there is one answer to these challenges: practice, practice and more practice to fine tune your craft. Well, developing software is similar in many respects.

Software development has it’s own thicket of variables to consider. There are the many functional and non-functional requirements that you must contend with, the different users involved (stakeholders, development team, system users, and the army of user persona’s) for the project, the changing requirements, resources and time that can impact the project, and various tools, technologies and platforms thrown into the mix as well.

Share/Bookmark

There is so much focus and investment put into developing a new software application that many people fail to see that completing the development isn’t the end of the road; it’s really just the beginning.

For one thing most people don’t realize that over the life cycle of a good software application, more development time is expended after the initial application is developed than within the initial development effort. While it’s a cliché, it is so true that “change is the only constant over the long run”. Therefore your application, no matter how well suited for your requirements now, will have to change over the years and evolve over time.

While ongoing life cycle software development can be the subject of future blog posts, my intention was to be more myopic today. I want to focus on what you’ll need to have in place when you are ready to launch as these requirements are often not well understood. This post will also not address any data conversion, integration issues, or related steps that may be required to implement your system. These are all valid issues but not today’s subject.

In the last 25 years, having resided in both the corporate world as CFO and a couple of times as the CIO and now on the other side of the table with organizations in the consulting world, I almost always see a gap in expectations. The root cause is that most people just don’t appreciate or take for granted what all goes into supporting an application. Even in the IT field, I’ve found that network people generally don’t fully appreciate what programmers have to do and vice-versa.

Let’s break it down. You’ll need to have services that we’ll organize into the following categories: hosting services, production support services, and software maintenance.

Share/Bookmark

Last time we came this way we looked at the misuse of a getter in the java.io.File. Not that it was wrong to have a getter in File, just that it led to misuse of that information in a UI control to determine what file encoding needed to be used to store the model.

This time we are looking at the Tally-ho CMS project. This is perhaps a more pernicious example of the shortcomings of getters and setters. We’re not having to remember rules about changing state here (that’s for an upcoming post), but we are exposing the implementation details and thus repeating code and making our application harder to change.

There are many places where ArticleBean is unpacked in the application. Here are just two examples.

Share/Bookmark

Photo by Nick Atkins Photography

An consistent nuisance problem when testing Rails applications is the “unit test gap”. This happens when the model test passes and the controller test passes, but the application as a whole fails because there’s a mismatch between the output produced by the model and the input given to the controller test. In theory, Rails integration tests can solve this problem, but they aren’t really designed for it, and nobody uses them much anyway.

An easy-to-use tool that solves that end-to-end testing would be great. Somebody should really write a blog post about that.

So, as I was saying. We continually run into an issue with our clients over defining requirements at the level that developers need to keep going, without getting bogged down in long stretches of design. There’s a big gap between “users should be able to upload photos to their pages” and all the different details of permissions, validation and the like than need to be answered at some point. The Agile process suggests that those requirements be created as closely as possible to the code, which leads to the question of how best to keep the customer in the loop while the developers need these decisions to be made.

An easy-to-use tool that lets users read or create requirements that developers can build from and run as acceptance tests would be great. Somebody should definitely write a blog post about that.

Which brings us — finally — to Cucumber, a tool for creating automated acceptance tests. It’s flexible enough to solve both problems. It can be used as a developer tool to drive regular TDD testing, and as a client tool for managing requirements.

Share/Bookmark

At some point in their career, most everyone in software development has encountered the client who paints a very eloquent picture about their fantabulous idea that’s going to revolutionize the [insert industry vertical here]. However, as time goes on you realize the client’s staying at the 60,000 foot level, and while that may make for great conversation, it’s less than ideal for actually developing something. The trick, then, is to get them to climb down into the trenches and define the details before you have to start writing the code.

At Pathfinder, we’ve been involving clients in creating business-driven scenarios to define a feature, i.e., what does ‘create accounts’ really mean. These scenarios walk through the different tasks of a feature and identify the expected behavior and outcome based on the user’s actions. Although they follow a specific format (context, events and outcomes), they are written in plain English that can be understood by all team members.

Share/Bookmark