Tag Archives: standards

Speeds ‘n Feeds

In technology, we’ve always gotten excited about so-called “speeds ‘n feeds.” The stats, the specs, the numbers that indicate performance. There’s a whole benchmarking industry for computers, for instance, that allow you to run the same test suite on your computer and check it against other models. In theory, that will give you an objective sense about how much faster/better one is than the other.

Except that when things are generally fast enough, or sharp enough, or have enough capacity, the speeds ‘n feeds don’t matter so much anymore. For the majority of the population that uses their computer to access the web and do office productivity stuff, the difference between a 2.7GhZ and a 3.0GhZ processor isn’t going to matter. Neither is 6GB of RAM vs. 8GB.

(A quick side trip – part of my mind still reels when typing those numbers; I remember when it was $100+ per MB of hard disk storage, and if you had 64K of RAM, you were rockin’ the best machine around. 8GB of RAM? 4TB of HD space? Amazing.)

So when the numbers stop mattering so much, what’s left? Experience and, to a lesser degree, features.

I was thinking about this yesterday, when the new iPhones were announced. As has been pointed out elsewhere, the new iPhone 5C is essentially a buffed-up plastic version of the iPhone 5. The iPhone 5S is a faster version (and 64-bit, which is actually a pretty big deal), with enhancements made to the camera and a new fingerprint sensor.

Now I’m an iPhone user, and we develop apps for the iPhone and other devices all the time. But I found myself stifling a bit of a yawn at times. Other than the 32-to-64-bit move, the hardware was an incremental step forward, but other than for fanboys and those at the end of their contract who need a new phone, it’s not going to move the needle much.

No, the ‘killer app’ of the presentation was the first part, where a slideshow-based demo of iOS 7 was done. Now this just might sell more phones. Parallax views, new sharing technologies, redesigned interface, easier access to more frequently-used things, intuitive use of calendar and mapping — this spells the foundation of a new experience altogether.

I think, at least in the phone world, we’ve entered the zone that PCs entered about a decade ago: speeds ‘n feeds aren’t so important anymore. How will the new thing (phone/PC/whatever) make me feel differently? Work differently? Live differently?

Should make for an interesting run for device makers everywhere.

The Power of Breaking Down Barriers

We all work in silos to one degree or another. Even with the integration of technology, very few of us are working with different people every day, solving problems with new coworkers each time. In fact, technology — while it helps to break down some of those barriers of time and space — also plays a key role in erecting new ones.

Think about a little thing like formats, for example. One canonical instance was the old videotape format of Beta vs VHS, where people who standardized on one type couldn’t meaningfully exchange video information with people standardized on the other. It still happens today with software and file formats, although the differences are lessening.

Or think about corporate competitors – if you’re standardized on Oracle financials, for example, it’s in Oracle’s best interest to make it difficult for you to migrate to a different manufacturer. One easy way to throw up roadblocks on that process is to establish proprietary formats that are difficult to match. (This happens in the CMS world all the time — Concrete5 is a perfectly-adequate CMS, but exporting all of its contents to migrate to someplace else is a royal pain!)

So it’s notable to me whenever an industry agrees on enough of a standard to be able to exchange meaningful data back and forth. And one industry that has done it — multiple times! — is the eLearning field.

Now they have been pushed along by large customers like the US military, but they still keep advancing the standards. Recently, a new API and standard called, alternatively, the Experience API or the Tin Can API, took the standards to a whole new level. Now, under this model, any bit of software can keep track of whether a user is learning or practicing a skill.

The implications are pretty big, if this gets ubiquitous. Right now, tracking your ability to learn a new Word skill, for instance, is limited to training programs that cover Word. What if Microsoft Word itself could track your progress? You’re doing an online course about how to mail merge, for example, and then you switch over to Word to practice — and the program feeds that information back to the online course, where you can get customized tips. Suddenly, everything can be about learning and professional development.

Pretty neat stuff – and it only happens when the barriers start breaking down. There are examples from other fields, too (especially through the power of XML), but those are for another day. If you’re so inclined, you should check out the Tin Can API. It’s got real potential!

Aspects of Love

Programming languages come and go at a frightening clip. Less often but still with some regularity, frameworks appear and disappear as well.

But it’s more infrequent that entire approaches to coding come along. Functional programming has been around forever. Object-oriented programming has been around nearly as long. But it’s only been a little more than a decade that the idea of <em>aspect-oriented programming</em>, or AOP, has been on the scene.

If you’re not familiar with AOP, some background might be helpful. A key idea behind AOP is that there are functions that your code needs to do which go across (or cross-cut) the entire application. In other paradigms, you then need to code bits of those functions all over the place. But in AOP, you do it only once.

One prototypical example is logging. If you’re writing an application that does anything significant, you probably write out to some kind of log when it happens. In a user-based application, for instance, you probably want to log every time you add a new user or delete a user.

Under other approaches, you need to call some kind of logging hook in your addUser and deleteUser functions (or methods). But with AOP, you can define a separate logging function, and tell it to attach to the deleteUser and addUser functions. The parts of the code that actually do the work with users aren’t touched at all.

Why is this helpful? Well, suppose you want to change how logging works or how you call the logging piece. You’d need to touch every place it’s called. With AOP, you just change the logging piece once, and you’re done.

Or suppose you decide well after the design stage that you want to add a layer of security to every user routine to make sure the person trying to make a change has permissions to do so. You could go find all of the functions and add calls to them, or you could just create a security-check routine and attach it to the relevant functions.

Compiled languages like Java and C++ have had this idea for a while now, but it has been slow to come to interpreted languages. With the Flow framework, for instance, PHP now has AOP capabilities. There’s still some roughness around the edges, but it’s a big step toward widespread adoption of this approach.

Watch this space…

Working With Style Guides

We work with clients big and small, so we run the gamut when it comes to design constraints. Sometimes, the client wants to start from scratch and gives us just a few parameters, while other times, we’re just making some minor changes to an already-established brand.

Somewhere in the middle is where we often find ourselves dealing with a style guide. This is a document from the client that outlines (in varying levels of detail) how their brand is represented across all media. Often, it has things like when and where to use the corporate logo(s), official colors, fonts, and that sort of thing.

We are used to working within these bounds, so that’s not a problem. But sometimes, the style guide can go just a little too far.

For instance, we worked with a client at one point whose guide specified the minimum size of the logo for display on the web at around 500 x 300 pixels, and that it had to remain on screen at all times. Think about this in a mobile perspective — that would take up most of a phone screen, and if it has to be onscreen always, then the content is doled out in 5-word increments!

It was clear in that example that the company hadn’t thought very clearly about the different devices and media that might be in play. Conversely, the reverse can happen as well — where the style guide is so vague that you’re not sure if you’re following the rules until you discover later that you’ve broken them.

Sometimes, we find ourselves in the position of creating these guides for clients, and while that can be tricky, it’s a useful reminder of the challenges involved.

What we’ve found is that even when a style guide is clear, it’s no substitute for good and open communication with the client. Sometimes what’s written isn’t what’s in practice, and it’s always good to get the straight skinny.