Flickr for Photo Workflow

Many higher ed institutions use Flickr to share photos with their constituents. We launched DU’s Flickr site this summer. We also set up an “internal” Flickr account for our overworked photographer Wayne. It was meant to cut down on his daily grunt work and, I’m happy to report, it has. Here are some of the efficiencies it has garnered for him since its inception:

  • Fewer in-person client reviews: Wayne is hired by various departments for photo shoots. After a gig, he used to schedule an in-person meeting with his client to review and choose the final photos that the client would ultimately take away with them. With the introduction of Flickr, he now uploads all the photos from the shoot into a Flickr set and gives the client access to it. The client then goes through and chooses the photos they wish to keep and deletes everything else. Our photographer saves himself an average of half a work day per week which frees him time to shoot other jobs, time to post process a client’s final selections and time to take care of non-billable, house cleaning tasks.
  • Fewer photo searches: Wayne, as the sole photographer for the university, continually receives photo requests for use in various materials (marketing collateral, website, banners, etc.). Each request required him to go through his archives and ferret out an appropriate sampling of photos. Clients would either come to him in person to review or he would burn a CD with images and send it to them. With Flickr, he is now able to send people to an online archive of photos (in this case, he sends them to either the internal account or the public one). Once there, clients can download high res versions of anything they find and know that whatever they come across is approved for usage.
  • Fewer variable costs: While not a huge area of servings, Wayne is able to cut down his use of CDs, jump drives, etc. because he now uses Flickr as a delivery method instead of physical media

Current Workflow

To make this work for Wayne, we plugged Flickr into his existing workflow so that his routine wouldn’t be overly disrupted. That process goes something like this:

  1. He downloads photos from his cameras into Lightroom
  2. He does a first pass through the raw files and throws out any obviously problematic photos
  3. He uploads the photos into a Flickr set using Jeffrey Friedl’s “Export to Flickr” Lightroom plugin
  4. If the set is uploaded to the public account, the set is marked as private and an automatic Twitter message is sent to one of our editors for title, description, and other metadata inclusion before being marked to public
  5. If the set is uploaded to the internal account, he gives his client access to the page and waits for them to choose the final shots they want

Truth be told, the above ideas are still being tweaked as the dust settles. Even so, Wayne has saved himself a good deal of work while our department has better served our internal clients as well as expanded our content offering to our various audiences (through direct hits to Flickr as well as embedding content into our core du.edu website- our annual report site is a good example of that).

Opportunities and Problems

One other workflow idea we’re working to incorporate now is to include the university’s archive team. The holy grail here is to have Wayne send his photos to archives for inclusion into their storage system and then pull the images we want to show in our public Flickr account from their database. The benefit gained is that Wayne has to send his work to archives anyway (per university policy) and, since the archive team appends a consistent set of metadata fields to each image, we can skip the step of using up an editor’s time to do the metadata work on the Flickr site.

Another idea we may try is based on an idea from Brad Ward. The jist is to use some fun gadgets to auto upload images in real-time from Wayne’s camera while he covers an event live.

One issue we’ve encountered is whether or not to make the internal account private or not. We didn’t, for example, want to post hundreds and hundreds of photos of any single event for public consumption, but Wayne has found that managing client credentials needed in order to access the private account was becoming more work than it was worth. So at the moment, all the photos are public, but not promoted in any way.

Other little issues have cropped up, but nothing that can’t be solved. We’ve reaped a lot of benefits from this move and are happy we did it.

Health Care Bill(s) & (Many) Higher Ed Websites

Some random connections:

  • Similar in that the “solutions” don’t account for the real audience that matters: patients / students
  • Similar in that those with ultimate decision making authority are swayed too much by lobbyists and insiders
  • Similar in that those in positions of power tend to be too insular in their thinking and don’t go out of their way to listen to their constituents
  • Similar in that opponents to change, regardless of whether it’s positive or negative change, use fear tactics as a mechanism to stop it (death panels / uncontrolled blog commenting)
  • The end product is, at best, a grand compromise that makes everyone, even the most important people it targets, suffer in needless ways
  • The old choice of “make it fast, cheap, or well- pick two” is turned into “make it fast, cheap, or well- pick all three” only to end up as “make it fast, cheap, or well- pick none.”

I’m sure there are others, but I’m already depressed having gotten this far.

Entropy and the Web

Websites want to be chaotic. They don’t like order, hierarchy, or staying on brand. Your efforts to tame it or control it are largely futile. The best you can do is point it in the right direction and then keep on eye on it. Turn your head for just a minute and suffer the consequences: broken links, inconsistent messages, oddball layouts, one time exceptions, and so on.

We usually clammer for more people, more money and more tools as salvation. They’re not. Those things will solve today’s problems, but new ones will arrive tomorrow. No set of widgets, plug-ins or third party add-ons will stop the inevitable. No workflow, processes or project manager from heaven stands a chance. Can you think of any CMS so good that it doesn’t let anything through the cracks? I can’t. Can we supersize it to an EMS and lick the problem? That’ll probably make it worse.

I bring all this up because after two days of great information and conversations at the AMA Higher Ed Symposium, It’s clear that higher ed is lurching forward in fits and starts to leverage all the wondrous new tools and services appearing daily on the Web. But in all the excitement and drama lies the everyday needs of everyone’s website. You’ve gotta remember to take care of the small, non-glamorous details that keep your site alive and well. Don’t lose sight of the daily grind because entropy is always there with you.

Is there hope? Well… just about the only thing any of us can muster in defense is vigilance. Stay attentive, be nimble and don’t let small problems fester into big ones. Keep the daily grunt work moving along efficiently, but also keep an eye on what’s coming up ahead. If the new thing on the horizon goes unchecked until it’s too late to deal with effectively, you lose. It’ll turn your hard work and good intentions into chaos and doubt. Don’t let it get to that.

Use link titles as a check on your architecture decisions

Recently at work, there was a discussion about link titles, their utility, when to use them, when not to and so forth. Link titles are those attributes you insert into a link tag that helps set expectations for users of where a link will take them. Conceptually, they’re easy to understand and rationalize. The hard part is actually writing them. I’m certainly guilty of writing banal descriptions that would make you wonder why I included one at all. But since no one ever calls you on them, it’s easy to let them slide. But over the years, I’ve come to realize that the seeming chore of title tags is actually an excellent check on your site’s information architecture. Let me explain.

Since title tags are an exercise in telling people what they’ll find behind a link before they actually go there, the act of writing it requires you to justify the relevance of the link in the first place. If you’re at Apple’s website on the Macbook page, you might see a link to their Macbook Pro page. Makes logical sense, right? If you’re interested in a Macbook, you might be interested in stepping up to a Pro model. A title tag might say “Step up to a Macbook Pro for added performance, storage, memory and more.” The sentence establishes relevance and a reason why you should click or not click. Job done, move on.

Let’s take another example, however. Let’s say you’re on a university’s annual report site, on any page. There’s a global link to the chancellor’s site. You write a link title that says… what? “Go to the website for Chancellor so and so.” No, that’s too obvious. “Get information about Chancellor so and so.” No, that’s not relevant to the annual report as a whole. “Get Chancellor so and so’s impressions on the year’s events.” No, if that information existed, it would be part of the annual report site itself.

The above reasoning hints at the utility of link titles. Writing them forces you to double check your architecture. Why does a link exist on this particular page or in the global nav? Is it relevant to include here versus over there? How does the inclusion of this link in this area on this page help the visitor accomplish their goals or further their aims?

All of these questions should have been asked early in the process, but things slip through or circumstances change. Writing link titles help verify that your user experience goals are kept intact and on track. Try it, it works.

Who is Your Client?

I’ve noticed that in higher ed, the word “client” refers to anyone except the school’s target audience. It’s usually a department head, an administrator or a project lead — essentially, anyone internally associated with the school. In an agency setting, that would make sense. You answer to the people who hire you because they pay your bills. In higher ed, though, students pay the bills, not your colleague in the next office. Internal personnel are your team members. They should help you (and you them) create the best experience for your true clients. Now, I’ve simplified things down to students here, but there will be others- donors, alumni, etc.- but you get the idea.

All employees at your school serve the greater ideals of the institution which, in turn, should ultimately revolve around the needs and wants of it’s various audiences. As such, an internal request must be measured against the established frameworks of the institution’s long term strategy. To say yes to every request will not only dilute the strategy and bottleneck any forward progress (because there will never be enough time and people to handle all requests), it’ll ultimately confuse and frustrate your true clients.

Time For Change

I haven’t posted for months. Not because I don’t want to, I do. The dearth of updates stems from an ever growing perception that what I write is hypocritical. By virtue of this site, I claim to have knowledge and insight into matters of strategy, IA and design, but in the 18 months I’ve spent at my university (on top of a decade’s worth of web experience), I have nothing of note to support the claims I’ve made here. The strategies, architecture and design ideas that I’ve put forth haven’t manifested themselves in the real world. I’m a believer that execution is what matters. You can sing the praises of your own ideas, that’s fine, but if you can’t make them real, if you can’t get them into production, then it’s just talk. So, without further ado and sans excuses (which is nearly killing me not to spell out), I’ll just move along.

This site used to be a fun place and I’m bringing that positive vibe back. So while I may continue to talk about web matters, I’ll mostly just write about my observations of the world. I hope that suffices to any readers left out there.

The Trouble With Titles

I recently took steps to get out of my current, part-time MBA program and into the executive version. To get some questions about the switch answered, I met with a program rep. One of the topics she wanted to cover was whether I met the minimum requirement of 10 years work experience. Having been in the web game for 12 years, I was a shoe-in. But she informed me that the requirement came with a caveat- the 10 years should show growth in management and/or increasing responsibility. Further, one way the school gauges an applicant’s worthiness is by their work title. That’s when “shoe-in” turned to “hmmm…” for me. I don’t consider titles in the web world to carry much meaning and have therefore never given them much thought or credibility. Want to know if someone is good? Look at their body of work and ask pointed questions. Want to get into an executive MBA program? Apparently, get a good title. WTF? At this point, “hmmm…” turned into “let me explain…”

My current title is Web Designer/New Media Specialist, a moniker bestowed on me after our university’s restructuring. Before that, I was simply Web Designer. I’ll take a wild guess that these titles won’t be looked upon favorably by the admissions reviewers. After all, after 12 years in the business, I effectively have the same title as I did when I started. The cynics out there might say, well maybe you’re a crap designer. Yeah, maybe. But after 12 years in the business, my work must be somewhat passable. Maybe I’m a jerk and alienate myself into low level positions. Maybe my bosses have researched my online profiles and think I’m a liability. Whatever the real reasons, my own self diagnosis for a lack of impressive title is due to my personal motivations and the age of the web. 

So back to the meeting. I found myself in a strange, apologetic tone. Surely, I needed to excuse my lack of title. Ironically, after my meeting, I was to meet with the Chancellor and Provost to present ideas on how a new website would save the university money, allow us to be much more customer centric than ever before, produce content with less effort and, in general, be more nimble and current in our approach. Isn’t this the kind of presentation a mid level manager at a big company would give to senior management? I thought about this juxtaposition for the rest of the day. What’s in a title? Why are web world titles so… arbitrary? And how do we, as a community, effectively translate our contributions via titles to outsiders?

Do Web Titles Do Us Justice?

There’s no doubt that I’m on the low rung of my university’s hierarchy (though I consider that the university’s loss). I have a breadth and depth of experience that my organization could put to effective use. Instead, my school has proven unwilling, unable or, worst yet, indifferent to fully utilize me. Why? I certainly hope it’s not because of my title. How disappointingly sad would that be- not only for myself but for the school? Would my job, my credibility and my contributions be any different if I had a title like Director of Web Communications or Vice Chancellor of All Things Web? Given the web team’s tiny staff size, I don’t think my job nor my contributions would be much different, but credibility? Probably.

When you only have a couple warm bodies available to work on a site with tens of thousands of pages and millions of yearly visitors like we do, you can bet that lofty titles or not, everyone does grunt work, everyone sweats the details and everyone is accountable to visitors. That’s just how it is from a practical standpoint. In this regard, titles in our industry don’t matter. What does matter, at least in my experience, is the promise of making great things. The web world is littered with people who want to elevate the web, and hence the organization, to a higher level. That seems to be the major motivation rather than fancy titles, corner offices or windfall year-end bonuses (though I wouldn’t turn any of those things down along the way).

The View From the Outside

The web, as we know and interact with it today, is a very young industry- 15 years, perhaps? My executive MBA peers, in contrast, work in health, finance, sales, etc.- professions that have been around for centuries, even millennia. Is it any wonder our industry still debates what our titles should be? It’s still too young and needs to sort itself out. 

For example, I’m considered a generalist in the field- someone whose skill set crosses many specialized functions. Other people consider themselves specialists- someone who knows all the ins and outs within a particular area like Flash or Ruby on Rails. Which is the right approach? Is one type of person more “senior” than the other? Should one manage the other, but not vice versa? The web is so collaborative and job functions are so permeable, a sense of hierarchy hasn’t solidified and this causes people outside of the business to easily misunderstand what it is we do and the importance of our work to an organization. Those things are changing, but it is slow. As Jesse James Garrett in the podcast linked above says, things won’t markedly improve for us until our group begins to house the VP and C-level ranks of major organizations.

Until then, I would argue that titles act as shorthand for your professional status. That’s why people are so concerned with their titles (since I’ve largely worked in smaller organizations surrounded by like minded people, titles haven’t mattered much). But I don’t find this race to the top as prevalent in the web. Maybe our young age has everything to do with that. Since we’re all relatively young, perhaps there’s a generational shift away from placing so much power and respect into titles. I don’t know. All I do know is that the admissions people who review my executive MBA application may not understand what my title of Web Designer really means or confers upon me. Hopefully they do, but until I’m sure, it goes without saying that I need to ensure that my title doesn’t arbitrarily stereotype me, demote my contributions or limit my worth.

There’s A Happy Medium Between Centralization & Decentralization

One of my main points of advice for higher ed websites is the idea that operationally, a decentralized management approach to the web does not work well. The opposite–centralization–does. But that doesn’t mean some aspects to a decentralized approach can’t or shouldn’t be employed. It just shouldn’t be the foundation for how to manage the global operation of the site. That spells trouble.

So where does decentralization make sense? The obvious answer is content. Higher ed sites are large, if not huge, relative to many websites and the thought of centralizing that amount of content into a few hands doesn’t seem practical. The sheer workload would jeopardize the distribution of time sensitive information. Plus, no content person wants to work in a sweat shop environment were quality takes a backseat to simply getting the work out. And beyond even those practical concerns, will a content person be as passionate about every subject that comes across their desk as the people who live and breathe it?For those reasons, content ought to be unleashed.

This isn’t anything new Mike

OK, so a decentralized content scheme isn’t a new idea, but my point is that simply because it’s smart to decentralize content creation doesn’t mean ALL aspects of the web effort should go along with it. This includes strategy, information architecture, visual design and functionality. There’s no credible reason that I’m aware of that would cause me to believe that every dean, vice chancellor, and director at the university should control how their part of the website works or functions. That’s not to say they shouldn’t be at the table to discuss matters that affect them, but neither should they be allowed to dictate needs on a per site section basis either. This is how workloads get out of hand.

Give me an example

If group A wants to promote news, group B wants to promote events and group C wants to promote both, what happens in a decentralized world? The web team gives each group exactly what they want. But if information architecture is centralized, then you would look at all groups in totality. You would take all wants and needs into consideration en masse. Only then can you create a solution that can be sustained over the long haul in an efficient manner. In our example, you might come to the conclusion that lots of groups across campus will want to promote news and/or events. So instead of building standalone news and event solutions plus one that handles both, you could merge news and events into a single steam called what’s happening. Any group on campus could then tap into this single solution. Group A doesn’t have events? No problem, no events populate their content, but the “what’s happening” label still makes sense. Same goes for group B in reverse.

Technology folks will of course try to build solutions with modularity in mind, but this only goes so far. News and events is an easy example since we all know those ideas will port across many departments. But what about requests that have limited universal appeal or practicality? Do you build it? The answer lies in your overall strategy. 

You may not have a global strategy precisely because of the decentralized environment. But once centralization occurs, that all changes. You should have a basic understanding of what your site is supposed to achieve and for whom. In that light, a request for a specific feature that is only useful to a certain group or for a particular, somewhat rare occasion should be looked at suspiciously. If your site is supposed to communicate with prospective students and entice them to apply, then there may not be a good case, for example, in building a Blackboard login function. I’m not saying Blackboard doesn’t have utility, but not for your prospective student audience nor to achieve your goal to drive applications . The correct answer in this case would be a polite “no.”

Instead, I see many sites, our own included, take on projects to fulfill any and all requests without much critical thought as to their strategic value. So more projects enter the queue, timelines stretch out, both clients and customers get frustrated over the slow progress, staff morale suffers and the website becomes ever more confused. I would imagine that if you looked at your institution’s workload, you’d find a significant amount to be, at best, tangential to your main goals and, at worst, unrelated at all. Kill those projects and focus. Centralize the high level, strategic functions your group provides while you decentralize the ground level content that gives visitors localized flavor.

Marketing ≠ Visitor Experience

I support the centralization of web operations in higher ed. Decentralized website management poses too many problems which centralization can alleviate. But gaining support for it poses problems within a system historically based on a decentralized system. One of those hurdles is the perception that a centralized approach kills the ability to market a school effectively. I say that’s nonsense. Continue reading “Marketing ≠ Visitor Experience”

Review: The eduStyle Guide to Usable Higher-Ed Homepage Design

Over Twitter, Cody Foss requested reviewers for a book about higher ed homepage design titled The eduStyle Guide to Usable Higher-Ed Homepage Design by Stewart Foss, Cody Foss and Andy Foss. I’m all over those kinds of requests and wrote back. Mere minutes later, I had downloaded the PDF and added the review to my long list of to-dos. I didn’t think I’d get to it sooner, but alas, the clouds parted, the gods looked down with smiles and I decimated my to-do list in order to get to it. So let’s get on with it, shall we?

Continue reading “Review: The eduStyle Guide to Usable Higher-Ed Homepage Design”