Flexibility to Accommodate Mobile

Many, many years ago I worked at a digital ad agency and a junior programmer was interested in trying out database design. The DBA let him give it a try. The comment the DBA had for the junior programmer was that he had done exactly what was asked for, but you have to try to anticipate people changing their requirements, and have your design be able to accommodate that. In this case, the database was going to be for people to answer some survey questions. Instead of making it to handle a specific number or questions with a certain number of optional replies the DBA said he should make it able to accommodate any number of questions, and each question should be able to handle any number of replies. It’s more work, but clients, designers, and account folks don’t typically think specifics like that are as important as perhaps they are.

There are a couple of modern equivalents in web development to the flexible database design. One of them is being ready for mobile.

Of course it would be nice to sell clients on accommodating the development of a mobile site or app while the project is being scoped, the fact is this doesn’t always happen. Sometimes it’s assume it will work on the bosses iPad. Sometimes they decide later it needs to work on phones. Or maybe they realize you were right, and they do want an iPhone app.

Thankfully Drupal is well equipped for such tasks. Two things you can do is make sure the them system you’re using to make your subtheme handles responsive design. Responsive design makes one site to serve them all that responds to the different sizes it has to deal with. Read up on it if you have the time, but even if you don’t, you’ll know you have it in your back pocket.

The other thing to do is check out the services module. When the time comes to make a mobile app the services module will allow you to make an interface for the iPhone or Android or whatever you’re building for, but it will leverage the system you already built. Plus, you’re not poking directly at the database – which is always a bad idea.

(This originally appeared on InteractiveQA.com)


developer, writer, speaker

You may also like...

Leave a Reply

%d bloggers like this: