Diet Coda
May 24, 2012

Downloaded Diet Coda today and I'm trying it out. Hope to re-install the blog software this weekend and make comments active again, not that anyone really comments here any more.

Gotta say, for the HTML/CSS editing that I do via iPad, this Diet Coda will be a godsend. Still have to see if I can stand for it to replace Dreamweaver. Probably can, but $50 (today only) for Coda 2 seems hefty. And if I wait, it'll be $100. I don't tend to use more than TextWrangler any more, though, so that makes me question whether I really need anything more complex than a text editor any more. Of course, it's always nice to be able to see where in the page I am ... but with responsive design, is that really viable anymore? Maybe it's time I give up the visual cue of the page and just code.

Meanwhile, back when I was attending the Neilsen Norman Group's Usability Week, I tweeted:

Eventually, the theory of responsive design (however it plays out), will finally get stakeholders to realize web is not print. It will get them used to the fact that a site design can't look the same in every screen and thus will also mean it won't look the same in every browser. I see progressive enhancement/graceful degradation & responsive web design theories blending together eventually. #webdesign

I've been thinking a lot about how my work has changed so much in such a short time. After all, the web as a mainstream entity didn't really exist when I graduated from high school and was only starting to gain traction outside of computer nerds as I graduated from college. I started designing websites haphazardly in 1997, I think, although I had a site a year or two earlier. I mean, if you can call it a website....

I have "grown up" as a designer as the web has also "grown up." When I started, the "best" way to make a site was shove images into table cells. It was a hack then and everyone who cared about how the site rendered  (users, designers) hated it. Everything was boxy to the user and kind of annoying and designers hated keeping everything boxy and hated marking up the page even more.

But the worst was "This site looks best in..." which was practically required if you had a complex design - it always seemed that a complex design simply was never rendered "the same" from browser to browser. You'd think that this fact alone would have been enough warning to us to realize that we were not working with the same media as print, the same constraints and rules. But, of course, we are creatures of habit far more than creatures of innovation and change. And our stakeholders were often even more convinced that this was just electronic print.

In the mid 90s, I was teaching first-year writing. I was one of the first in the department to put my entire syllabus on the web. I begged the head of the department to let me take over the department's site design from the undergrad who'd originally built it. The site was not bad by the standards of the time, but each page was different. Without any class in human computer interaction, no lectures on usability, no formal training in information architecture, not even a single design class under my belt, I knew that websites needed more coherence than the department's name up at the top of each page.

I threw up a site more quickly than I preferred using a piece of free software called NaviPress, an early "WYSIWYG" program. The intent was to go back and learn HTML as soon as the spring semester was over so that I could "do it right." The first site was ugly, simple and usable enough. It was a backup of the paper syllabus. My students were, by and large, privileged and most had computers with them. The school had multiple 24 hour computer labs for those who did not have computers and all of them had computers at home. I was smug in the thought that my students could never claim to have lost their syllabus - it was online.

I had the entire site backed up on disk and the first day of class, two IT guys wheeled in the cart with the computer setup but were unable to connect to the internet.

No problem, I was practically giddy with my foresight. I whipped out the disk and proceeded to get through the class, showing them the website saved locally. The IT guys were surprised and grateful. The students were curious. 

That summer, I taught myself HTML a little more systematically. I didn't buy a book, I didn't take a class. I simply viewed a lot of source code. I chatted with a few people in the rec.toys.misc newsgroup who were also interested in the web. For the longest time, I thought web guru Eric Meyer and the Eric Meyer from RTM were one and the same. By the next summer, my website's ugliness embarrassed me. I had taken "staff classes" at the university where I taught as an adjunct and learned a little Photoshop, a little Dreamweaver and a fair amount of Fireworks. I was also starting to pick up Flash as well. I was well and truly hooked.

As a teacher, I strove to know my audience. After all, the clarion call of the writing world has always been to know the audience. You must pitch your writing style, your vocabulary, your points to a specific audience in order to reach them, persuade them. I saw teaching the same way. Yes, I had a slew of topics I was supposed to cover, but every semester was different, presenting different people with different skill sets, different needs. I was always a semester "behind," spending any time in between semesters tweaking the class according to evaluations and other feedback from the students. More than once, I completely stopped class to get feedback as to why something wasn't working and what we as a class needed to do to get things back on track.

It was not long before my website embarrassed me. I had learned so much in a short time and I was beginning to truly understand the power inherent in the medium. I could do more for my students. So one summer not long after I began putting the basic syllabus on the web, I planned out a new version. I spent time first deciding what should be on the web, how it should be organized, what types of formatting the different pieces of content needed. I agonized over how my students thought, how I could best present the most important information like due dates and daily schedules. I wanted them to have no excuse for not knowing the information they needed.

Then I went to work on the look. I don't recall now if I did a full mockup in Fireworks; I do remember that some pieces (like the buttons) were template specials, not created from scratch. I was so proud of the finished product. I'd used everything I'd learned about my past students. I'd provided multiple routes to the most important information in order to catch their different ways of thinking and processing and searching.

And two-thirds of the way through the first semester using it, one of the students finally blurted out that he couldn't find a damn thing on the site.

I'm pretty sure that my jaw actually fell off of my face and hit the ground.

I wish I recalled that student's name and I hope that he got half as much from my class as I did by his single statement, because he taught me the most important maxim of my web career:

Your website is never done.

You will always be tweaking your designs, your architecture, your content, your layout. Always. The web is a living document in a way that your print syllabus is not.

The web was much the same as teaching a class. The best instructors were fluid, adjusting to their students' needs on the fly and still striving to reach all of the curricular goals, but tailoring them as they went. It was a philosophy I embraced whole-heartedly, but I had originally made the mistake of thinking the essential layout and architecture were somehow exempt from that. 

That was my first lesson in what I have come to think of as holistic web design. The second lesson revolved around a tension between design, usability and audience. 

And I think that stakeholders are finally starting to learn the same thing now. You can view a site on a multiplicity of phones, tablets, computers. They all use different operating systems and different screen sizes. None of them looks exactly the same — at least, not without spending a ridiculous amount of time and effort and extra code to get that effect. Whilst I know that some poor managers simply assume that a coder's "inability" to get a page or detail to look exactly the same in all browsers is either laziness or incompetence on the coder's part; I firmly believe it's becoming easier to convince them that you don't WANT the site to look exactly the same on every screen. You want a comparable experience. You want it to be easy to do whatever task the user wants. But the context is as different as the screen size in most cases. And the more we push for well thought-out responsive design, the more I think they will agree with us.

That said ... it's past time for me to redo all of my sites. None of them are responsive. All of them adhere to fixed pixel designs. I need to make time to practice what I believe.

Truly, your website is NEVER done.

Posted by Red Monkey at May 24, 2012 8:21 PM | Design | | StumbleUpon Toolbar Stumble |

Free Pixel Advertisement for your blog