Don’t Go Chasing Waterfalls

Let’s assume that you’re going to build an XML-based publishing system. You’ve gathered requirements from the various stakeholders, have a design in mind, and have vendors or your own people lined up to make it happen. You’re good to go. You still have to decide one key thing: how will this system be built?

We really didn’t think about this. We came up with a fairly standard method to manage our project. Requirements gathered. Check. Systems designed. Check. Programming implemented. Check. System tested. Check. Boom. Done.

Sounds fine, right? You need to do certain things in a certain order to accomplish anything. But then reality hits. What if the requirements aren’t captured completely? What if the design doesn’t deliver what was expected? What if, and this is completely hypothetical because it never happens in the real world, something changes during the course of the project?

We weren’t consciously aware of it, but we had adopted the waterfall method of project management. The whole project with all its moving parts is considered at once. Everything is developed at the same time. When one stage is finished, that’s it, because it’s very detrimental to the schedule and budget to revisit past decisions and do rework.

Why is this a problem? Because this programming methodology was developed when guys in white shirts and skinny ties were doing projects on room-size computers that only the richest kings of Europe could afford. You had to have everything planned and ready to go because your computer time was Thursday from 4-5:30. These people did amazing things of course. You try launching rockets to the moon using only punch cards and slide rules.

Of course today, in the impossibly futuristic year of 2009, computers are somewhat more available. There are computers in greeting cards that play stupid songs when you open them. Then you throw them out. My washing machine has more computing power than that room-size thing from 50 years ago.

So why would we use such an outdated project management methodology? I don’t know. Seriously, who thinks about stuff like this when you’re trying to build a hugely complex new thingie on time and within budget? Well, add it to the list of things to talk about while planning a project.

It became clear during development that our methodology was hurting, rather than helping us. The core reality of our existence was, all together now, WE DON’T KNOW WHAT WE’RE DOING. All the requirements and design done before implementation were based on our assumptions and the prior experience of our vendors. Speculation, really. An image of the future that we thought made sense at the time. Something like this.

Then the thing gets built and the testing starts, and we realize we’ve made horrible mistakes. Gross miscalculations. Silly omissions. And, by the by, the market has changed a bit during all that planning so some of the stuff we planned for and built was no longer needed, and new things that were now needed weren’t included because, um, they didn’t exist during the planning phase.

Inflexibility is the downfall of the waterfall. It’s just too costly to redo the thing once it gets started. Rather than rethinking and reworking major missteps, we were forced to make slight modifications to what we had, which resulted in inadequate solutions and workarounds. Spending all that time and cash, and ending up with something that doesn’t quite do everything it needs to do is beyond disappointing.

Next week we’ll look at another methodology that may help solve some of these problems.

Not Thinking Out of the Box

This is kind of a continuation of the content management stuff I’ve been writing about. It pertains to software in general though. In our case the problems were with the content management software, but anytime you’re developing something based on a commercially-available platform, this issue comes into play.

It’s silly, but in our rush to bend our content management system to do what we wanted, we neglected to really explore what it already did. That is, we didn’t familiarize ourselves with the “out of the box functionality*” that we were getting.

My main excuse is, of course, the familiar and painfully true: WE DON’T KNOW HOW TO DO THIS. Once again, it would have been nice if our vendor had helped us out a bit more.

One of our team members raised the warning during a UI review-type thing where the vendor showed us an interminable presentation depicting in stunning wireframes the UI representation of each use case. So basically, “if you want to do XYZ, click this button and choose this menu item.” Oh, yes, it’s just as exciting as you’re imagining right now. And did I mention it was in PowerPoint, and we were projecting the slides in a dark room? Probably right after lunch?

Our team member, who wasn’t dazzled by the 2-d renderings, asked a simple question along the lines of “what do all those grayed-out menu items do?” You’d think she’d hurled a molotov cocktail at the presenter’s head based on the reaction. The presenter, the other reps from the vendor, and our own corporate project manager all basically told her “don’t worry about it” but used more and louder words with wavy hand and arm gestures.

Undaunted, she pressed on, asking something like “but don’t we need to know everything this does before we can tell you what we don’t want?” Again, the arm waving and near-apoplexy with the general message of “we’ve already figured that out for you based on your requirements.”

Oh, my. It pains me to recount this ugly incident. And, like cowards throughout history, I went along with the loud majority, in this case our vendor. Because of course they have our best interests in mind, and they’re the experts, and they’ve assured us that this really is the way we want to go. And the second payment is due next Friday.

My colleague let it go, but with a “you guys are wrong and this is going to come back to hurt you” look that haunts me to this day.

Obviously, she was right. Months, and even years, later, we’d come across something that didn’t quite do what we wanted, or we’d have a new requirement pop up. We’d ask our (completely different) experts how to make it happen. And imagine our anguish when they told us “this is already supposed to be in there.” And the absolutely devastating “in fact, somebody had to do a really complex workaround to shut off this core functionality.” And the humiliating “why did you want them to do that?”

The lesson should be obvious: if you’re using commercially-available software as part of your publishing solution, you’d better have a REALLY good reason to disable features and functions that are already available. I mean, come on. What were we thinking?

(* And may I just say how much I detest the word “functionality**”. But even more, the fact that after being bombardized by it for so long I end up engaging in its utilization because it provides optimal expressionality for my core meaningness? This instantiates my angrificity, which renders me beyond uncomfortabilitated.)

(** I did, though, enjoy titling a user guide “Utilizing the Functionality!” The exclamation point means fun!)

Publicious Links: The Hoist The Jolly Roger Edition

Y’arr, mateys. Your captain has sworn off rum in favor of GoogleJuice, so this week’s meme be pirates. Has anybody seen a stray parrot, answers to the name of “Preflight”?

By the way, according to the bean counters, InDesign CS4’s Live Preflight is worth more than a chest of Spanish doubloons. Well, OK, about $5 a week. Check out the Pfeiffer Report on CS4 ROI for details (Adobe ID required for download).

Next, read my 5 Random Tips at InDesign Secrets or I’ll have ye swab the deck.

Prepare the boarding party, part 1: More speculation on Apple buying Adobe.

Prepare the boarding party, part 2:  More speculation on Google buying Twitter.

Jack Sparrow just threw a squid at you on Facebook. Captain Hook’s posted a YouTube clip. Blackbeard’s tweeting up a typhoon. How do you get a handle on all the pirates in your life? Try an RIA that gathers all your social networks into one place, like Skimmer.

Flex Marks the Spot: Here’s a nice (and thorough) look at best and worst practices in developing a rich internet application: Architecture of RIA.

If your skull and crossbones is looking a little tattered, design a new emblem to strike fear into all who cross your path. psd tuts+ has an eye-popping tutorial on creating a Hellacious Flaming Skull in Photoshop.

Speaking of Photoshop, John Nack has announced that PICT is about to walk the plank. Wonder what InDesign and Illustrator features we can safely send to Davy Jones’ locker…

Till next week, I wish smooth sailing to you. And remember, dead men click no links.

The Bits and Pieces VII: Content Management (Practice)

Text assets, which make up the vast majority of our content, are a little trickier to manage than images. Text is everything from one letter to every letter we’ve ever written. Because the content management system defined assets as objects (or files), we needed to figure out how much text would go into each file.

First we identified all the products the publishing system would create. That’s one level of division for the text assets. But how practical is it to have to check out an entire book if you just want to edit a piece of it? We needed to identify smaller parts. The products could be divided into things like units and chapters. Smaller yet were things like quizzes and worksheets. And then there were the component parts that made up all those quizzes and worksheets. Where to draw the line?

We decided to create a new kind of content level, which we called Activities. The capital A was meant to differentiate these content assets from certain worksheets that were called “activities.” From an editorial perspective, an “activity” was a particular kind of thing with a particular structure and purpose. An “Activity” broadened that definition to be the “smallest teachable part.” In other words, what’s the smallest indivisible content chunk that a teacher would likely assign to a student, or that we would provide for the teacher as a professional development or classroom management tool.

An Activity could be one page, or part of a page, or several pages long. The concept of “page” was not important here. The information conveyed by the Activity had to be a single unit of content that could stand on its own. This is a tricky concept to explain to people who are used to thinking of everything as pages in a book.

There was one other content chunk that we normally dealt with on an individual basis: test items. Test items can be reused in a variety of products. If you have 1000 test items on a particular concept, you can mix and match them to create different products for different audiences. We knew this. We also knew that our content management system had to manage everything as a separate object, with separate metadata, and separate listings within the user interface. In other words, if we managed items individually, we’d have screen after screen of test items that you’d have to scroll through, or search, to find the one you’re looking for. This sounded obnoxious and difficult to deal with, from both a programming and user perspective.

Stupid thing 2: Sacrificing business requirements for development expediency.

It would have been very difficult to manage test items as separate assets. But test items are an extremely important part of our products. Maybe they’re the most important things that our publishing system would store, manage, and output. Our developer (who didn’t want to deal with it) advised against it from a time and money standpoint. Our team was more than happy to agree, because it would have been a pain for us to come up with the metadata and management strategy as well as the user experience. By that point the project was already getting behind schedule, so dropping this big challenging thing was very easy to do.

What we should have done: Suck it up.

Yes, even with the ensuing complications, we should have built the system to manage items as separate objects. Maybe it would have made the content management experience more difficult and slower than it already was. But it would also have made the system much more flexible and useful in its original mission of creating products from stored assets. The trade-off may very well have been worth it.

Now I’m not saying that you have to put in everything all at once. We had to sacrifice all kinds of things to schedule and budget. Most of them were small features that would have helped a small group of users, or were for a small group of products. And we had workarounds for all of them. Or we added them later. Leaving out a huge, core, central piece, one of the main reasons to do the whole project in the first place, was not a smart move.

Stylin’ Appearances

Graphic Styles are among my favorite tools in Illustrator because they give you so many options and can save you so much time. Styles in general are terrific — Graphic Styles, Character Styles, and Paragraph Styles — and I will go into detail on all of those some other time. Today I want to focus on graphic styles because I use those the most and I find them to be my biggest time savers. Plus, when you apply them to fonts they give you some really cool type effects and I just love me my type effects!

You can make graphic styles as simple or as complex as you need. Let’s start with an apparently simple one — a circle with a 3 pt blue outer rule, a 4 pt white inner rule, and a tinted blue fill. You could actually draw concentric circles, but if you wanted to draw several different sized circles it would a time-consuming nuisance to have to calculate the sizes of the inner circles so that the proportion of the outer dark blue rule and the inner white space stayed the same. You can’t just scale them because they will keep their relative proportions and resize thicker or thinner depending on which way you scale the circles, like so:

picture-1

So the easiest way to maintain consistent proportions on the concentric circles is to create a style that you can then apply to circles of different sizes. The way you create such a style is by using the handy appearance panel, which I like to keep grouped with the layers panel since they present data in a similar manner. You start off with a single stroke and a single fill option but you can add additional strokes and fills to create the appearance you want, using the way the strokes and fills stack the same way you would use layers.

picture-2

To create a style for this appearance, I created a circle with a fill of 50% blue, a 7 pt white stroke aligned to inside, and a 3 pt. 100% blue stroke above that also aligned to inside. By placing the 3 pt. stroke on top of the 7 pt. stroke, that gives me a visible inner stroke of 4 pts. (7 – 3 = 4) and placing the fill underneath all of it creates the inner circle. Now the proportion of outer rule and inner rule stay the same no matter what size circle you apply it to, as you can see here:

picture-3

Let’s take this simple set of circles and create a style that’s a little more fun. Instead of a solid color fill we’re going to use a patterned fill and apply an effect to it. If you already have some patterned fills you can use those or you can load one of the many patterned fills included in Illustrator — I’m using “Wild Flowers Color” from the Nature_Foliage collection and I used a color from one of the flower groupings for the outer stroke. Now we’re going to add an effect to make it more interesting. Select the fill, then go into the Effect menu and select Stylize, then select Inner Glow. Set Mode to Multiply and make the color 100% Black, set the Opacity to 60%, the Blur to 15 pts., and click on Edge.

picture-6

As you can see, this gives the appearance of having a cutout over a print. The only thing you need to be aware of is if you are using a large tiled pattern fill, the area that is being used will change depending on where on the page it lies. If you have a particular area you want to use as your focal point you will need to expand the fill, which will also cause the rest of the pattern to appear under the clipping path.

picture-8

Not only can you apply effects to the elements in a graphic style, you can also use the Transform effect to move one or more of the layers for even more fun, and these are the ones that can be so impressive when applied to type. In this week’s download is a graphic style that is set up similar to the ones mentioned above, but I’ve also gone in and used the Transform effect to move the strokes down and to the right as well as adding a drop shadow to the fill. It’s not so impressive when applied to a path, but with the right typeface, it looks like a famous sandwich cookie!

picture-9

Once you have everything set up the way you want it, all you have to do to make it a graphic style is to select the path and drag it over into the Graphic Styles panel, then give it a descriptive name. To apply that new style to a path, just select the path and click on the name in the panel.

Stylin_Appearances.ai

Pub Links: The Play Ball Edition

Ah, springtime in Boston. The last remnants of dirty snow cower in the shadows near big box parking lots. The Emerson girls are trading in their UGGs for flip-flops. And with the first pitch at Fenway, the looooooooooooooooooong winter of ’08–’09 was finally, officially, over ’round these parts. Now ladies and gentlemen, boys and girls, introducing the starting lineup for the 2009 Publicious GREP Sox.

Batting leadoff, and playing centerfield, O’ReillyMaker lets you customize your own version of those iconicly weirdo book covers.

picture-3

Batting second, and playing shortstop, a must-have iPhone app for fontgeeks: Bitstream’s What the Font? for iPhone. With it, you can go to the grocery store, snap a pic of a box of Cocoa Puffs, and WTF will tell you what typeface that crazy rooster has been dancing in front of lo these many years. I think it’s HelveticaBlackExtraCuckoo.

Batting third and playing second base, Squidspot’s Periodic Table of Typefaces.

Batting fourth and playing first base, David Pogue’s blog post on landscape vs. portrait orientation for PDFs. Touches on a lot of issues of readability and design.

Batting fifth, the designated hitter, the story of how the InDesign spell checker caused a controversy that lead to a newspaper recall. Actually, I think it was probably the person using the spell checker. But fine, throw ID under the bus. It can take it.

Batting sixth and playing left field, Apple and Adobe: The Odd Couple. Steve Jobs has to be Felix. Who at Adobe would be Oscar?

Batting seventh and playing right field, the Cut & Paste Digital Design Tournament in Chicago.

Batting eighth and playing third base, Adobe and Facebook getting social.

Batting ninth and catching, an anagram maker. Some of my faves:

Helvetica = A tech evil

Adobe InDesign = bondage inside, deadening bios, disdain begone

Publicious.net = bionic pustule, polite incubus, unlit poi cubes.

And the starting pitcher, THE greatest Looney Tune of all time: Baseball Bugs.

The Bits and Pieces VI: Content Management (Practice)

Naturally, the first question we considered as we developed our content management strategy was: what content are we going to manage? We create all kinds of products, but were only focused on a subset for our project. So we concluded that we’d need to manage text and image assets for the particular products the system would make. Makes sense so far.

Images are relatively easy to manage. Each image is a file. Sometimes an image is made up of several other images. We had to have a philosophical discussion around these. Is the image that contains other images a new, unique asset; or, is it a compilation or reuse of other images and only exists as a different container for those other images. We went with the “new image” concept because the act of combining images created an indivisible content chunk. Or something. Whatever works, I guess.

The content management system we were going to use managed assets as separate objects. The objects could be assigned a “type” having mostly to do with the file format of the asset. The objects could also carry “attributes”, or metadata. The attributes could be anything we wanted them to be. So we had to figure out what we wanted them to be. Per our usual routine, we gathered representatives from each of the groups who would be using and managing the assets and asked them what kind of information they’d like to see attached to each asset. And we got a very long list. Even after editing it down we still had a very long list.

Stupid thing 1: Overdoing it.

There are lots of aspects to image management. There are content concerns, such as “what’s the image of.” There are design concerns such as “what’s the color space and resolution.” There are permissions concerns such as “who owns the copyright.” There are tracking concerns such as “where has this image been used before.” They’re all necessary. But do they all need to be addressed in the content management system? I guess the answer is “it would be nice but only if the system can handle it.” And ours couldn’t. At least not very well.

The problem with sticking all that metadata on an asset in the kind of system we were using is that every time you want to do something with that asset, all that metadata comes along for the ride. We had screen after screen of metadata that a user could fill in whenever they checked in a file. The problem is that not every user cares about all the metadata. I believe the current version of the content management system addresses this problem by assigning certain metadata to certain roles as defined by a user’s account profile. But we didn’t have that option. So, the task of editing a file and checking it in took an extra couple of seconds because all that metadata had to load, and the user had to click through several screens or scroll a long way before the OK button showed up. Multiply those seconds by all the images someone would be working on in a day, and you end up with an unhappy user.

What we should have done: Stick to core needs.

We were not building a contract and permissions tracking system. The image specs such as color space weren’t going to be used by the system to do anything. The overall goal wasn’t to create an art library, it was to create products by assembling assets. So we didn’t really need most of the metadata. We needed to manage all that information of course, just not in the system we were building.

Eventually, it would be nice to have a centralized system that could manage all the assets and metadata. The new publishing system we’re designing now may try to address that need. It would be great to have one place for various groups to do their business. But only as long as the system can handle it, the users aren’t inconvenienced by things they don’t need, and the overall goal of the project isn’t compromised.

More stupidity next week.