The text-based life

As I’m working through the droidification of my life, I’m struck by two truisms… First, the auto-substitution give and the auto-substitution take away even as it slowly learns that words like ‘droidification’ should not be rendered as ‘driving fiction’.

Secondly, I realized as I was pondering my bill this month, that I live a predominantly text-based existence, for a geek. I am an Infocom game running on a Warcraft engine… a lot of power for text adventures.

Still, recognition is the first step for recovery. it isn’t so much about me needing to change my lifestyle because I bout a phone… its actually a professional consideration. Increasingly a large number of projects are encompassing the mobile space, so I need to immerse myself in the lifestyle as far as I can. My thumb speed is already improving, and I’ve started taking some interesting photos pc my daily life. I just haven’t started uploading or sharing them all that much yet. Small things like that are part of what I mean.

One thing I did find today….GDOC. It’s an app that will let me edit Google Docs from my Droid. See? Text-based little ole me.


Felicitactiones a los mineros Chilenos

I want to express my own joy and best wishes to the Chilean miners rescued today. Welcome back from the underworld, guys.

Examining my mobile use

After my last post about Providing my life I took a look at what my actual usage patterns on the phone actually are. I realized that it isn’t so Mich a question of whether or not I’m usually.g the smartphone or not, its more a question of the kinds of things I’m actually using it for.

In the past few days I have:
– Finished reading Ken Collect’s novel Deadly Fortune via the Kindle app for Droid, even though I don’t have a Kindle. Then I downloaded Machiavelli’s The Prince and Sun Tzu’s Art of War to have on hand in the office.

– I downloaded Florence + The Machine and have played it until I’ve got the music stuck in my dreams.

– If you count my last post and this one I’ve blogged from the phone (trying to ramp up thumb typing proficiency and seed the Droid auto-replace library with my own language patterns.

– I’ve had sms conversations wih lots of folks.

– took pictures of my workday scenery for later editing and sharing on Flickr.

– counted calories

I suppose given all of that I’ve been getting along well, and I’m already Droidifying nicely. I’m convinced that there’s more I can be doing or getting out of this phone.

One thing I’m planning on doing next is working more on setting up the various user spaces to organize
my apps a bit more logically to me. From there we’ll see about adding photos to the flogging. And learning more about the PhotoShop express app and what it can do.

Droiding My Life

In July I finally made the step up into the world of smartphones and purchased a Droid Incredible for me and my partner. It was super cool, and having a smartphone finally gave me the context for a lot of my old grad school classes which just wasn’t possible before.

Recent work conversations about mobile made me take a look at my pattern of usage with the Droid, and I came to realize that aside from using the Droid like an iPod (another item I never owned) and taking a couple of 8Mpx snaps that essentially, I’ve been using the Droid the exact same way I had used my old flip phone.  For the price of a Smartphone, not exactly good use of my money.

I’ve decided, therefore, to start Droiding my life.

I want to start putting the phone through its paces and see what I can really do with it. It’s going to be a bit of a lifestyle adjustment, but I’ve already made the investment in materials, so now I need to make the investment in time.

For the next six months, over the winter, I’m going to be trying out new things to see how I can really get the most out of my Droid. It means some conscious decisions about my other online patterns as well. For example, do I want to spend more time taking and manipulating photos for Flickr and become active as a digital artist there, or should I work within Facebook more via mobile? Do I *really* want to bother with Twitter? That kind of thing.

I’ll keep you posted on my progress.

Net Neutrality resource

There’s been a bit of a hiatus in my blogging here about internet things due mostly to a real live job consulting with BBDO in Manhattan for a while on an attempt to do some internal interactive startup work. The gig is closing out soon, and in the windup I’m happy to repost a great infographic about why Net Neutrality matters and what some of the interactive kerfluffle is all about.

Please note that I have no affiliation with nor do I sponsor the ‘Online MBA’ site which posted the infographic. -ap

Online MBA Programs
Via: Online MBA Programs

Demystifying the Interactive Process [Part VI – Deployment]

By this stage the development is done, the code is married to the front-end designs and the internal team has had their chance to crawl around inside the guts of the interactive piece to break it before the Client or worse, the end users break it themselves. Once the internal team has had their chance to check their own work, the work gets turned over to the Client. At that point, we’re out of Development and moving directly into Deployment.

Although you might be tempted to dismiss Deployment as a ‘simple’ or ‘easy’ part of the process (‘just wrapping things up’), Deployment is perhaps the most busy time in any interactive project, with the most amount of ‘rushes’, ’emergencies’, and ‘fire drills’ happening. Do yourselves a favor… don’t schedule Launches of major interactive projects unless you can devote a good 80% of your attention to the Launch on the day it happens, and 40% on the day after it happened. For this reason alone, unless there’s a specific market driver to the date, never schedule a launch on a Friday or before a weekend. You -want- there to be staff in the agency’s office 24- to 48- hours after any major launches. Launch on a Friday and you’ll be stuck waiting for tech support til Monday morning (or paying for overtime).

User Acceptance Testing/UAT

Deployment kicks off with a phase known as User Acceptance Testing, or UAT. This is the time when the project, typically in a staging server environment (e.g. it doesn’t live where it’s going to be served up to the public, yet. Like Nike developing a site redesign on vs. something up at… just making up theoretical examples here). Everything is built and “done” from the initial round of creation’s standpoint. The project itself should exist and work in its final state, with only content tweaks and minor facade-level changes being made per Client requests. If you hit UAT and end up making architectural- or structural-level changes to the site that you didn’t plan for originally, then raise the red flag and get ready to move back into Development, or even Definition phase.

What to expect from UAT as a Client

During UAT, the Client is given the link to the project on the staging environment, and then they are given a set amount of time to find anything wrong or to break the site. At this stage of the game, what you as a Client -should- be doing is navigating to your project link from as many different computers, on as many different platforms as possible. You should be creating test scenarios and walking through sample interaction points to test and make sure the database is working properly, or to get a real sense of any problems that a typical user will encounter. What almost always happens, though, is the Client representatives give a good proofreading of the site and send back feedback which is aimed at how the site -looks- more than how the site -functions-.

At the very least, you as a Client should open up the Functional Specifications document which was created back in Definition, as well as the Wireframes document, and you should go page by page trying to do all of the actions and activities in the Func Specs, Use Cases, and Wireframes. Note any area where what was promised in the documents doesn’t work as promised in the project, and bring those areas up with your Producer. Either there were decisions which were made between the Func Specs and UAT which didn’t get updated in the Func Specs for timing reasons, or else there’s going to need to be a proper explanation why something promised from a functionality point of view is not being delivered as per agreed-upon expectations.

When all looks good and matches the written documentation or has been explained to satisfaction, the Client submits a formal approval to the agency and pulls the trigger on the rest of the Launch process.  If the web site is particularly large or involves complicated functionality, you might have a Formal Site Walkthrough meeting where the Agency walks the Client team through the website one, last time. At the end of Formal Site Walkthrough and any fixes that come about from it, the Client signals approval, and we move forward to the actual Launch process itself.

Code & Content Freeze, then Launch

Once the Client has approved the final project, the Agency developing it should issue a formal Code and Content Freeze. This is the point beyond which no changes will happen to the project until after the project is live. You need to freeze the coding and content revision process because part of what it means to have ‘flexible results’ within the Interactive Process is that coders and designers and content creators could and will tweak things to death unless you give them a point at which it’s hands off before launch.  What are they changing? Adding documentation, adjusting layouts, adding content, tweaking presentation of content, small tiny things that can be done at any time once the site is live.

Next will come the Launch process itself. Typically, the more complicated projects involve a series of coordinated steps where the new server space is created for the project, the hardware is set up, the files are transferred over, the DNS registry is updated, and finally, the site goes live.  To track all of the moving pieces and infrastructure-level sysadmin tasks, good Producers will generate a formal Launch Plan document and review it with both the internal team as well as the client team to present a checklist of launch steps.

Other projects will be so simple and straightforward that all you need to do is copy the files to the new, live server, or turn on the DNS registry changes and you’re done. Every project is different. If Agency or Client begins to feel iffy on the steps involved in the Launch, it takes about an hour to draw up a Launch Plan and circulate it for approvals. Don’t be afraid to ask for one, it’s one of the many services an Interactive Producer will provide.

The Post-Launch Scramble

It always happens. The site is perfect, every team member who ever heard the name of this project or went to school with one of the other team member’s children or siblings signs off on every document ever created… the project goes live…. and suddenly the CEO on the Client side is looking at this gem of an accomplishment that the Client team put together, and clicks on a broken link. The ONE broken link that escaped Inspectors 1-12 is the ONE link that the CEO clicks, gets an error message.

The Client Team goes into immediate panic mode and contacts the Agency team with a note of stern rebuke and strained panic in their voice to inquire, nay, demand to know why this one link wasn’t caught! Yes, it’s horrible that it happens and everyone takes great pains to ensure that everything works, but I have to tell you, these things just happen from time to time, and it’s always the Client Team’s high ranking supervisors who happen to find them.

This is why, as an Agency, the Launch is the busiest period of time. There’s going to be something wrong. You just hope it’s cosmetic (“You misspelled Smythe on page 2.4.12, second paragraph”) instead of structural (“We were supposed to put the Mission Statement in both About Us and Contact Us, but it only appears in About Us right now”)  or worse, catastrophic (“The password login screen brought me to the last user’s shopping cart, complete with credit card information populating all the fields”).  Knowing that no matter how vigilant the QA and UAT process is that there’s just going to be -something- that needs to be fixed or which doesn’t work -as expected-, as an Agency you need to ensure that there are dedicated resources on your team who are ready to drop everything else they’re doing to immediately tackle any unforeseen problems that crop up STAT so that the newly launched site gets rid of any hiccups -before- the general public notices them.

Once the project has launched and it’s out there, live, on the net, with all the immediate bugs either fixed or in queue to be fixed, then Deployment has been achieved. You might be tempted to think that this marks the end of the Interactive Project Development Lifecycle, but you would be forgetting two of the most important steps of all which follows any launch:  Measurement, and Maintenance. We’ll talk about Measurement next in Part VII.

Bringing Law to the Lawless

In Judge Dredd, the judges “retire” by taking ‘The Long Walk’, out into the Cursed Earth where they will spend the rest of their days “bringing the Law to the Lawless”.

I’ve recently been assigned to new clients at my freelance assignment, and I found myself thinking last week “This feels an awful lot like bringing Law to the Lawless,” as compared with my experiences on another global client here where everything was so turn-key that I didn’t really have to think much.

I found out today that there’s good reason for this feeling I’ve been having — these are the clients who haven’t yet worked with a Project Manager on their accounts, and in a very real way bringing Law to the Lawless (or “Process to the Unfettered”, I think more accurate) is exactly what I’m doing.

Lucky me.