<ul class="search-results">

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=37">Upgrades immanent</a></h2>

        <p class="excerpt">&hellip;It looks as though Dean is close to releasing the next beta of Textpattern, the content management system on which this site is run. I&#8217;ll probably hold off for a couple of days to see if anyone has any major problems, and then upgrade.
            Expect outages &#8211; they will happen. It&#8217;s a beta, baby. Also due for an upgrade is Apple&#8217;s iPod according to Think Secret. In other news, http://www.welovetheiraqiinformationminister.com/.&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=40">Web users don't read</a></h2>

        <p class="excerpt">&hellip;I read Derek Powazek&#8217;s <em class="keyword">Design</em> for Community quite some time ago when it first hit the shelves. I&#8217;ve always admired Derek&#8217;s sites, and consider a visit to ({fray} tell your stories) to be pure
            indulgence. I&#8217;m involved in building community sites myself these days, so have been re-reading selected parts of Derek&#8217;s book. It was only today that I came across this article on the book&#8217;s companion site. Words of truth,
            eloquently spoken.&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=42">On the subject of RSS</a></h2>

        <p class="excerpt">&hellip;In today&#8217;s Daily Report, Jeffrey Zeldman weighs up some of the pros and cons of personally published sites offering a syndicated news feed. Having recently started using and publishing in RSS, I felt that there was more to the discussion
            that Jeffrey was letting on. I needed to make clear my own opinions on the matter. It&#8217;s disagreeing with someone that does that. I monitor a number of personal sites via their syndicated newsfeeds. The ones I keep an eye on are typically
            the ones that are updated frequently (maybe once or twice a day), that I typically wouldn&#8217;t have the time to read otherwise. Without visiting each site in turn, I can quickly see who has posted new content, scan-read the new post, and
            if it&#8217;s interesting I hit Enter and the site itself opens in a browser window. (Reading direct from a newsreader is dull as rocks). This works well for me because I can find the content I&#8217;m interested in quickly, and then still
            enjoy that content to its&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=50">The people's web</a></h2>

        <p class="excerpt">&hellip;I&#8217;m involved in a whole load of different online groups and lists where people (often newbies) ask questions about web <em class="keyword">design</em> and development. The usual occurrence is that someone will ask a question and
            they will get an answer to their question and a description of what is wrong with what they&#8217;re doing. I have to admit I do this too. What&#8217;s up with us? This has to be wrong. I&#8217;m very passionate about building a better web.
            I strongly advocate the use of web standards and general good practices. I can get anal about it at times. The worst thing of all is that I do it in the face of those who are simply trying to get their content online. I&#8217;m risking coming
            down so heavy with what their doing wrong that it obliterates what they&#8217;re doing right &#8211; namely publishing their content on the web for others to share. Taking a purest line, no one should publish anything on the web unless it
            is &#8216;clean&#8217; and &#8216;valid&#8217;. However,&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=65">Object, Echo, Tango</a></h2>

        <p class="excerpt">&hellip;Mark Pilgrim&#8217;s article The Vanishing Image: XHTML 2 Migration Issues over at XML.com takes a thorough look at Internet Explorer&#8217;s implementation of the HTML object element. Whilst being interesting reading from an XHTML 2.0
            point of view, it also makes excellent accompanying reading to my Flash Satay article at ALA. (Hat tip: James Ellis) Also worth a mention is The Echo Project, which I&#8217;ve been following for the last 10 days or so. The purpose of the project
            is to explore defining a new content syndication, publishing and archiving format, independent of any particular vendor, for the free use of the community. The planning is all going down on Sam&#8217;s Wiki, and comments are invited from anyone
            who has a valuable contribution to make. It&#8217;s very interesting reading, and a worthwhile project to give support to. Mike Jones at Footnote* Consulting has relaunched their site this week. If you&#8217;re a <em class="keyword">design</em>            or development outfit looking for some overflow&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=78">Oh look ...</a></h2>

        <p class="excerpt">&hellip;Anyone recognise the <em class="keyword">design</em> of this site? It reminds me of something, but I can&#8217;t quite place it. This was discovered courtesy of an interesting looking blog I can&#8217;t read. Can anyone translate? Unrelated,
            look what comes up when you go to Google and search for find a guy. Google adjusts its results constantly, but at the time of writing, this site is coming up as the number 1 result. (Can you tell I&#8217;ve been searching through my referrer
            logs?)&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=81">Usability on the cheap</a></h2>

        <p class="excerpt">&hellip;The Register reports on the new UK government Illustrated Handbook for Web Management Teams launched last week. Despite some questionable impositions like the mandatory use of frames on homepages and would-you-believe-it the requirement
            to use HTML 4.01 to ensure compatibility with all browsers, (Have you found a browser yet that won&#8217;t happily digest carefully written XHTML?) the framework is generally well meaning and offers reasonable advice. One suggestion within
            the document is to save money on usability testing by getting students and family involved. I can see how that is actually a great idea for certain sites that are working to a budget, but if those people aren&#8217;t your target audience you
            can&#8217;t make them pretend that they are. In usability testing you need simple, honest reactions. Anything else and you&#8217;re kidding yourself. It&#8217;s not the most coherent of documents, not is it technically accurate to the extent
            it should be, but it would seem&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=88">Attention Fireworks and Photoshop users</a></h2>

        <p class="excerpt">&hellip;To all Fireworks and Photoshop/ImageReady users:- Go ahead, <em class="keyword">design</em> you sites in a professional image manipulation program. That&#8217;s a good thing to do. It helps with layout, it helps in defining a specific
            look and feel, it gives you control and creative freedom all in an environment built for the task. But: keep the hell away from the automatic HTML export features. Repeat after me: &#8220;No matter how good my intentions, automatic slicing
            and dicing does not a good website make&#8221;. To the following files:- transparent.gif, shim.gif, spacer.gif, pixel.gif. I ended our relationship more than two years ago. Please stop contacting me like this. I do not wish to see you again.
            You were to me but a last resort &#8211; and I truly believe that&#8217;s all you will ever allow yourself to be. Please respect my feelings and leave me alone. To the head chef:- This week I had the misfortune to sample your Tag Soup. It
            was foul tasting and left me feeling somewhat nauseous. Many high&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=89">Re-Useit Design Contest</a></h2>

        <p class="excerpt">&hellip;Today Bob Sawyer announces the Re-Useit <em class="keyword">Design</em> Contest. The name of the game is to re<em class="keyword">design</em> Jakob Nielsen&#8217;s useit.com.

            <em class="keyword">Design</em> a usable, intuitive layout and navigation, organize the content with usability in mind, and create a work of art which still reflects the importance and influence of Nielsen&#8217;s work. Basically, it&#8217;s
            a chance to show that usable <em class="keyword">design</em> isn&#8217;t necessarily dull <em class="keyword">design</em>, and what better way to demonstrate it. Bob has asked me to sit on the judges panel for the contest, so I&#8217;m looking
            forward to seeing the results.&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=102">The times they are onchanging</a></h2>

        <p class="excerpt">&hellip;Browsers are getting better all the time. Those being worked on in the open source community like the Mozilla family of products are getting better every day. Add to that browsers like Apple&#8217;s Safari (which is based on the open source
            KHTML rendering engine) and the collective browsing experience is just getting better and better. Even Internet Explorer hasn&#8217;t been left too far behind with companies like Google developing free add-on toolbars offering functionality
            such as pop-up blocking. One feature a lot of browsers seem to have (and offered by the Google Toolbar for IE) is Form Autofill. This useful utility allows you to enter a common set of information such as your name, email address and country,
            and then have the browser automatically fill out form fields based on that data. A real timesaver. But &#8230; As web <em class="keyword">design</em>ers/developers we need to be careful. Typically, (I haven&#8217;t found one yet) form auto-fill
            features can behave a little unpredictably with the&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=104">Dear Apple Computer</a></h2>

        <p class="excerpt">&hellip;Congratulations on the launch of your new PowerBook range. Yet again, you have paved the way with cutting edge <em class="keyword">design</em> and innovation. Please would you consider making a gift to me of a 15inch PowerBook. I would
            put it to exceptional good use, and would tell everyone how great it is. I would gladly buy one myself, but I am a sorry mess. Please don&#8217;t consider this to be begging. I am not begging. I am offering you a unique marketing opportunity,
            a sponsorship opportunity, the opportunity for tremendous positive publicity in the struggling UK market, and also I want one really really badly. I look forward to your response with eager anticipation. Yours, Drew McLellan P.S. Pleeeeease!&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=107">The IC-Style</a></h2>

        <p class="excerpt">&hellip;According to Joe Clark I am a perpetrator or what he calls The International Compliant Style of site <em class="keyword">design</em>. I&#8217;m not sure how to take that. I guess to be cited as an example means that I have executed my
            <em class="keyword">design</em> style well. My site is in the IC-Style, not emulating it. That has to be good. On the flip side, Joe is saying that my <em class="keyword">design</em> is a mass-produced unoriginal. That said, simple, clean,
            easy-to-read and &#8216;less is more&#8217; are hardly original concepts, so I&#8217;m pretty happy in my unoriginality. The vast majority of sites that try to be avant-garde (like the Flash examples Joe cites) fail to make good on their intentions
            and end up obscuring their content in the process. I know I don&#8217;t have the <em class="keyword">design</em> skills to be able to pull off a really usable, visually stunning <em class="keyword">design</em> and besides, that&#8217;s not
            what my site is about. That&#8217;s not what you&#8217;re here for. So I guess I&#8217;m happy in my IC-Style. At least if I&#8217;m going to be part of this&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=119">It's just this damn XML</a></h2>

        <p class="excerpt">&hellip;I started working on a nice little personal project in PHP. It has a specific real-world use, and in evaluating the approaches I could take with the <em class="keyword">design</em>, I decided that it didn&#8217;t need a database. Rare
            for me. I like databases. The only data this application needs to store is general system configuration settings, which I thought would be best stored as a simple XML file. I like XML &#8211; much more than databases. So I began carrying out
            proof-of-concepts on each of the major parts of the project. I searched on the excellent php.net for the XML functions, and found them. Hmm. Why is PHP&#8217;s XML implementation so crap? How has it managed this long without DOM support? I
            can see it&#8217;s on its way, but how has everyone been managing? Do PHP developers not care about XML? I&#8217;ve settled with parsing my XML file out into an array of arrays (yuk), which is useable but hideous and putrid. I think I&#8217;m
            going to have to <em class="keyword">design</em> my application in such a way as when&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=128">ReUSEIT judging underway</a></h2>

        <p class="excerpt">&hellip;So the ReUSEIT contest has closed for new submissions, and the judging has commenced. I can&#8217;t comment on the entries, other than to say that there has been some excellent work done. Everyone who took the time and entered deserves
            recognition for their achievement. For me as a judge, this raises issues. Whilst I know attractive <em class="keyword">design</em> and good quality code like the back of my hand, one of the primary objectives for this contest is usability
            <em class="keyword">design</em>. I can tell you what bad usability looks like. Bad usability is usually accented by grunts of desperation and another trip to the coffee machine. Good usability, on the other hand is transparent. As it happens,
            judging usability with an A/B comparison is easy. Suddenly the plus and minus points leap off the page at you much more readily then they do when looking at a single page in isolation. So here&#8217;s a tip for today: when attempting to assess
            the usability of a site you&#8217;re working on, compare it to something similar&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=129">New job</a></h2>

        <p class="excerpt">&hellip;So the dot.com work came to an end (as dot.com work does), and yesterday I started work at a new place. I&#8217;m back in my natural habitat of a <em class="keyword">design</em> agency, and working again with my old friend Mr Pitman, which
            is splendid. I won&#8217;t link to our website yet, as I&#8217;m about to start building a new one (the current site is pretty old and doesn&#8217;t do the company justice), so there&#8217;s something to look forward to. On an unrelated note,
            today is Guy Fawkes night here in merry old England. There are fireworks going off everywhere &#8211; the sky is alight. Both Rachel and Mike are getting particularly grumpy about it all, which in itself is rather amusing.&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=136">Application Interface Design</a></h2>

        <p class="excerpt">&hellip;Over at Digital Web Magazine this month, Jean Tillman from Unisys discusses an issue close to my heart &#8211; User Interface <em class="keyword">Design</em> for Web Applications. Whilst the article is refreshing in its subject matter
            (you don&#8217;t hear a lot of talk of AUI <em class="keyword">design</em> online), there are quite a few specific practical points in the article that I disagree with. For the last three years or so, my 9 to 5 (and quite a lot of my 5 to
            9) has been taken up with specifically <em class="keyword">design</em>ing and building web applications &#8211; so on reading some of the points in Tillman&#8217;s article I felt the need to respond. A user might fill out the same form many
            times (for example, to add several user-IDs to the database), so it’s not important to distinguish which pages have been visited. In cases like this, it’s preferable to specify the same color for the unvisited links as for the visited links
            so all links look the same. Whilst I agree that main functions within the application should not indicate a&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=137">Creating and Designing Your Own Personal Disaster</a></h2>

        <p class="excerpt">&hellip;In the BBC article Creating and <em class="keyword">Design</em>ing Your Own Print Ads, the author suggests that With the wide availability of computers and <em class="keyword">design</em> programs, it is now possible to be your own
            <em
                class="keyword">design</em> agency. With attention to detail you, too, can produce your own professional-looking advertisements. With the wide availability of building materials I could build my own house, but that doesn&#8217;t mean it wouldn&#8217;t fall
                down. The suggestion that someone should try and produce their own print ads instead of focusing on their business and what they do best is absurd. Not only do you have the expense of buying additional software, you then have to learn
                how to use it and finally hope to goodness that you have a thimble of talent somewhere in your body. After much expense, several headaches and many many hours of hard work you might just get lucky and come out with something good. If your
                business doesn&#8217;t go bust in the mean time, you might just get away with it. Alternatively, you&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=16">About</a></h2>

        <p class="excerpt">&hellip;Everyone has an about page. It&#8217;s how you know what someone&#8217;s all about. I&#8217;m all about the about. Mmm metadata. So here follows some of that, beginning with one of those awkward third-person biographies. Awkward third-person
            biography Drew McLellan has been hacking on the web since around 1996 following an unfortunate incident with a margarine tub. Since then he&#8217;s spread himself between both front- and back-end development projects, and now works as a Web
            Developer for edgeofmyseat.com in Maidenhead, UK. Prior to this, Drew was a Web Developer for Yahoo!, and before that primarily worked as a technical lead within <em class="keyword">design</em> and branding agencies for clients such as Nissan,
            Goodyear Dunlop, Siemens/Bosch, Caburys, ICI Dulux and Virgin.net. Somewhere along the way, Drew managed to get himself embroiled with Dreamweaver and was made an early Macromedia Evangelist for that product. This lead to book deals, public
            appearances, fame, glory, and his eventual&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=183">Web Standards Solutions</a></h2>

        <p class="excerpt">&hellip;If you&#8217;re the sort of person who follows developments in standards compliant <em class="keyword">design</em>, chances are you&#8217;ll be familiar with the work of Dan Cederholm of SimpleBits.com. Even if you&#8217;re not familiar
            with the name, you may recognize his work on the standards compliant re<em class="keyword">design</em>s of FastCompany and Inc.com, and his recent article for A List Apart. Over the past few months I&#8217;ve had the pleasure of working with
            Dan myself &#8211; I&#8217;ve been the Technical Reviewer for Dan&#8217;s new book. Web Standards Solutions: The Markup and Style Handbook is a real solutions-orientated guide to using standards-based techniques in your daily work. Dan doesn&#8217;t
            just suggest what you should be doing when developing a site, but rather goes on to explain how to do it in real, honest and practical terms. The format of the book takes its linage from the SimpleQuiz features Dan runs on his site. That&#8217;s
            to say that each chapter starts of by posing a problem or <em class="keyword">design</em> issue,&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=186">Take-out Interfaces</a></h2>

        <p class="excerpt">&hellip;Ordering food over the phone can be tricky. Typically all the best take-out places are run by folk who learned their craft in distant countries and for whom English is not their first language. Add to that the noise from busy kitchens
            and a selection of hard-to-pronounce dishes, and placing an order can be a real nightmare. Not to mention the fact that I&#8217;m a geek, and by my very nature I hate using phones at the best of times. (Who knows how to work those things anyway?)
            I have, however, been very impressed with how my local Chinese take-out place has focussed its efforts on making orders easy to place. They&#8217;ve carefully considered and <em class="keyword">design</em>ed the customer interface and made
            optimizations in a number of key areas. First off is the menu itself. Every item on the menu has a number as usual, but at the bottom of each page is a specific instruction &#8211; Please order by number. By making numbers the default mechanism
            for placing an order, they let the customer off the&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=189">Defensive Design for the Web</a></h2>

        <p class="excerpt">&hellip;I&#8217;m usually the first person to quote the mantra that no software is bug-free, especially as I&#8217;m usually the one who&#8217;s written the code, but the inescapable fact holds true that if something can go wrong it will, and
            that bugs will be found by the end user no matter how much testing you do. In real-life systems (like shops and restaurants) if something unexpected happens, the people involved just adjust to cope. We&#8217;re human beings capable of intelligent
            thought and able to adjust our actions based on whatever comes our way. The show must go on. In contrast to human beings, the software we use on a daily basis is completely deterministic. The flow of the program can be logically followed,
            including any choices made based on the users input. That&#8217;s essentially how software works and how it&#8217;s written. For software to cope with different situations the developer has to preempt what those situations might be and to
            code responses to them. Considering&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=193">Icons for Web Applications</a></h2>

        <p class="excerpt">&hellip;Some people are really good at <em class="keyword">design</em>ing icons. However, those of us from Earth find it tricky to say the least. This is a shame, as a web application can be made or broken by the quality of its interface and currently
            a major part of any interface is its icons. So what&#8217;s a girl to do? You can try <em class="keyword">design</em>ing your own. It&#8217;s at this point you realize that 16&#215;16 pixels isn&#8217;t so big. You quickly find that anything
            detailed comes out as a blob, and anything simple comes out as a blob. Unless you&#8217;re looking to <em class="keyword">design</em> an icon for the user to invoke the blob command, you&#8217;re somewhere short of your goal. So you decide
            to get outside help. You try to find a freelancer or contractor to <em class="keyword">design</em> some icons. Any freelancer or contractor you ask will claim that they can <em class="keyword">design</em> icons. Every freelancer or contractor
            will deliver you a collection of 80 icons for invoking the blob command. Face it. Unless you have someone on your team who is the bastard child of&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=195">Page 23</a></h2>

        <p class="excerpt">&hellip;Keith told me to: Grab the nearest book. Open the book to page 23. Find the fifth sentence. Post the text of the sentence in your journal along with these instructions. From a book called Defensive <em class="keyword">Design</em> for the
            Web by 37signals: This poor messaging is bound to create further confusion. Well, quite.&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=203">Writing The Code is the Easy Bit</a></h2>

        <p class="excerpt">&hellip;Software <em class="keyword">design</em> is hard. Yeah, I know no one said it was easy, and it&#8217;s certainly a lot of fun, but damn it&#8217;s hard. I&#8217;m currently working on a PHP/MySQL based content management system, largely
            based on the lessons I learned after spending the best part of a year building an ASP/SQL Server based CMS for a different company. But you know what? The decisions don&#8217;t get easier with experience, they get harder. When building a system
            that is going to be used by real life users (who have paid you money and know how to use a telephone) you learn an awful lot about your products very quickly. You find out what sort of things the users want to do that you hadn&#8217;t anticipated,
            and you learn what features are going to be requested. You also learn the limitations of your architecture and framework, and before too long you can begin to curse those decisions that you made early on. They say ignorance is bliss &#8211;
            and that&#8217;s certainly true when it comes to&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=204">Experience is More Important than Knowledge Of Syntax</a></h2>

        <p class="excerpt">&hellip;I&#8217;m still pretty much learning PHP. Having a lot of experience in ASP, and going back further, perl, stands me in excellent stead. Over the years I&#8217;ve taught myself a number of different languages, starting with BASIC when
            I was roughly seven years of age, so I&#8217;m pretty comfortable with reading technical documentation and gleaning the information I need. After all, when <em class="keyword">design</em>ing a web application (as I&#8217;ve noted previously)
            it&#8217;s the logic that is key, rather than the code. Code can be looked up. What you can&#8217;t gain from the manual, however, is the lessons learned from experience. The user comments on PHP.net give a snapshot of various peoples&#8217;
            experiences, but it&#8217;s incredibly hard to learn from other peoples&#8217; mistakes when it comes to code. The manual can tell you how to use each aspect of the technology, but it won&#8217;t tell you what&#8217;s best to use in each precise
            circumstance. There are some things you just have to learn&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=212">And Breathe Out</a></h2>

        <p class="excerpt">&hellip;PHP has been giving me the run-around. Just when you think you&#8217;ve got it all sussed out it springs another surprise. It likes to play with me that way &#8211; show me who&#8217;s boss. This afternoon Nathan and I launched a site
            we have been working on for months. More accurately, we launched a site based on the content management system we&#8217;ve been working on for months. She flies! Hurrah and all that. Up until the site going live today I&#8217;d been validating
            pages using one or other of two methods. The first thing I tried was installing the W3C validator on my dev server. That almost worked, but no matter what input I gave it seemed to be resolving paths to the wrong site. I don&#8217;t think
            it liked by VirtualHosts set up. Being too pressed for time to really fiddle with it, I resorted to saving the output of a view source to disc and uploading the file to the W3C service. This worked fine. On enlivening the site this afternoon,
            I took the opportunity to run the&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=213">Scalability vs Performance</a></h2>

        <p class="excerpt">&hellip;When <em class="keyword">design</em>ing the architecture for a web application, it is normally desirable to <em class="keyword">design</em> every aspect of the system to be as scalable as possible. It&#8217;s only too often that badly
            <em class="keyword">design</em>ed apps have need to be completely refactored before any further development work can be done, entirely due to an unscalable architecture. If the app hasn&#8217;t been <em class="keyword">design</em>ed with an
            attitude of what if we wanted to &#8230;? then adding a dot-dot-dot six months down the line can be a massive undertaking with needless slaughtering of otherwise good code. But we know this; we know that applications, any code in fact, needs
            to be <em class="keyword">design</em>ed to cope effectively with change. It&#8217;s one of the principals behind OO and it&#8217;s generally accepted as A Good Thing. This is typically done through the use of OO <em class="keyword">design</em>            principals closely coupled with various levels of abstraction. The question it raises, however, is where do we stop? At what point does multiple levels of abstraction stop saving&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=227">Web Development is Software Development</a></h2>

        <p class="excerpt">&hellip;With a considerable amount of the world&#8217;s web development being performed in a context focussed on visual <em class="keyword">design</em>, it&#8217;s easy to see how that work can get pushed to the side a little. That&#8217;s not
            to say that the importance of development work isn&#8217;t recognised, but perhaps that the nature of the work isn&#8217;t recognised for what it is. Within the context of a web shop or <em class="keyword">design</em> agency the tendency is
            to approach development aspects of a project in the same way as the <em class="keyword">design</em>. However, development is not the same as <em class="keyword">design</em>, and the processes and management of such work has to reflect this.
            When all is said and done, web development is a flavour of software development. Of course this is both a blessing and a curse. Recognising your projects as software development means enacting all sorts of formal processes and procedures,
            and having to worry about nasty stuff like specification documents, bug tracking and team structure. The upside to this is that the software&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=236">CSS Anthology</a></h2>

        <p class="excerpt">&hellip;Rachel&#8217;s got a new book out aimed at anyone who uses CSS on a daily basis to just get stuff done. The CSS Anthology: 101 Essential Tips, Tricks and Hacks answers a succession of those quick how do I &#8230;? questions that constantly
            crop up when working with CSS in a production environment. The publishers, well respected web <em class="keyword">design</em> and development resource site SitePoint say the following: The CSS Anthology: 101 Essential Tips, Tricks &amp; Hacks’
            is ideal for experienced Web <em class="keyword">design</em>ers who would like to add sparkle to their existing <em class="keyword">design</em>s, as well as newcomers who want to learn Web <em class="keyword">design</em> the right way the
            first time. The book is written so that it can be read cover to cover, or referred to like a cookbook with 101 different recipies for your Website. It&#8217;s written in an easy-to-follow, consistent format that&#8217;s well illustrated with
            plenty of screenshots and code examples, providing quick visual cues. If you hate wading through dry academic-style&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=237">Supermarket Usability</a></h2>

        <p class="excerpt">&hellip;It&#8217;s an undeniable fact that supermarkets are <em class="keyword">design</em>ed to make us buy things. The science of supermarket <em class="keyword">design</em> is widely practised with the intent of guiding shoppers to purchase
            not only as much as possible, but the specific products the supermarket wants us to buy. From the positioning on shelves to the layout of the store, every effort is made to control the behaviour of the shopper. This, almost by definition,
            flies in the face of what we might term supermaket usability or even consumer friendliness. The customer&#8217;s objective is to get into the store, collect the things they need, get to the check-out and leave as quickly as possible. Organic
            Peas An example &#8211; the other day I needed to pick up some garden peas. We try to buy organic whenever possible, so I was initially pleased to see a section labelled &#8216;Organic Vegetables&#8217; in the store. The supermarket were trying
            to promote organic veg, and I had been led straight to it. The fact that there were&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=245">Designing URIs</a></h2>

        <p class="excerpt">&hellip;So this is a quick hack of a post I&#8217;ve been spending far too long failing to complete. Time to just get it out the door. If parts are nonsensical, please accept my apologies. You get what you pay for. A fair bit has been written
            over the years about <em class="keyword">design</em>ing good URIs. Whilst traditional teaching on the subject must also apply to web applications to some extent, how far does it go? Does the nature of the documents being served (in this case
            &#8216;active&#8217; documents as part of a larger application) hold sway over the URI of the page? First Principals I tend to be pretty fussy about what appears in the location bar of any sites or apps that I architect. Partly this is down
            to aesthetics and some idealist goal of elegance, but primarily it rests with the core values of sustainability, perception of stability and also ease of use. Let&#8217;s unpack that. The subject of sustainability in URI <em class="keyword">design</em>            should be familiar to us all. At a base level, /contact is good, but&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=247">User Defined Functions Considered Harmful</a></h2>

        <p class="excerpt">&hellip;I admit I should have listened to Rachel. She told me that SQL Server user defined functions (UDFs) were evil, but in the face of zero evidence to back up her claim, I went ahead and <em class="keyword">design</em>ed the linchpin query
            in our latest project using beautifully <em class="keyword">design</em>ed logic blocks all extracted out to UDFs. The query is exceptionally complex, having to take account of countless business rules and turn them into result set filters.
            In fact the query is the crux of the entire web app, with all roads leading to its door. In order to <em class="keyword">design</em> the query to be as elegant and maintainable as possible, I made heavy use of UDFs to compartmentalise each
            rule. The <em class="keyword">design</em> of the query was pretty good &#8211; with carefully chosen function names the whole thing read more like a screenplay. And in development it ran beautifully. Now we&#8217;re in alpha testing, and the
            client has begun loading data. The primary table has about 40,000 rows, and there are perhaps a dozen joined tables containing anything up&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=249">Emerging from the Shower</a></h2>

        <p class="excerpt">&hellip;I share a similar discomfort with the term ajax as I do with DHTML. Back in the day we took the concept of HTML styled with CSS, made interactive with JavaScript and accessed through the Document Object Model, and termed it DHTML. This
            act alone made it easy to describe how those technologies could be used together for what was, at the time, innovative things. The same is true of ajax. It stands of Asynchronous JavaScript and XML, which in turn stands for look at me I&#8217;m
            a geek and you don&#8217;t understand what I&#8217;m saying. It does, however, give us a useful way of describing the whole xmlhttprequest thing and how JavaScript, XML, server-side code and out-of-process HTTP requests can interact with HTML
            to make interfaces a little more interactive/responsive. We don&#8217;t use the term DHTML any more because what was innovative when the term was invented is every day now, and no one needs a generic term to describe that stuff. We all know
            how HTML, CSS, JavaScript and&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=251">Everyone Has a Clock</a></h2>

        <p class="excerpt">&hellip;If you build web sites for a living, you will no doubt have come across a client who, despite lack of any logic or reason, wants either the time or date displayed on their site. Unlike a vast number of other common web <em class="keyword">design</em>            sins, I have to say that this is not one I&#8217;ve ever fallen foul of (despite working on a number of sites that have already been cursed with the presence of the day and/or time before I inherited them). Whilst there are a small number
            of cases where it makes sense to present the user with a timestamp (project management tools like Basecamp spring to mind), most of the time it&#8217;s an unnecessary waste of space. Most commonly used browsing platforms, including my S60
            phone, have a clock built in. If I want to know the time or the date, it&#8217;s only a brief glance away. There&#8217;s no need to waste space on the page by reiterating the obvious. Today I was at the Science Museum in London, and was interested
            to see their exhibition of computing through&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=265">Upgraded to Textpattern 4.0.1</a></h2>

        <p class="excerpt">&hellip;I&#8217;ve been running a fairly ancient build of Textpattern on this site since I relaunched with this <em class="keyword">design</em> back in August last year. Since then, TXP has undergone massive changes, and some important security
            fixes have been made. Although none of the potential security problems are known to have been exploited, I was getting pretty itchy about it and thought I&#8217;d better update. The main reason I&#8217;d hadn&#8217;t upgraded sooner was that
            I&#8217;d hacked around with my install quite a bit to get the markup how I wanted it. There were some quirks with TXP a year ago, and some of the markup was still hard-coded into the files and not exposed to the templating system. So I thought
            that upgrading to v4.0.1 would be a major nightmare, and had pretty much resigned myself to biting the bullet and getting on with somehow, anyhow getting my site upgraded. I was pleasantly surprised to find that I had to do absolutely nothing.
            I checked out the latest stable build from svn,&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=279">Site Maps for Web Applications</a></h2>

        <p class="excerpt">&hellip;Site maps &#8211; and by that I mean the information architecture documents used in the web site <em class="keyword">design</em> and production process, not the catch-all navigational monstrosities found lurking in footers far and near
            like some trenchant swamp-thing biding time to attack &#8211; are pretty much the de facto method of visualising site structure in a way that can be documented. They&#8217;ve been around for years, Jesse James Garrett has come up with a formalised
            visual vocabulary for expressing them. Known, perhaps not loved, but certainly tried and tested. Site maps generally fall into two different categories:- those that document the navigational structure of the site, and those that describe interaction
            flow. As the days of enormous, static sites vignette to make way for sites driven by logic not links, we naturally see a shift in emphasis from navigational maps to those which document interaction. The question worth exploring, however, is
            can this form of documentation continue to prove&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=295">The Biggest Unsolved Problems of Web Design</a></h2>

        <p class="excerpt">&hellip;As a result of travel arrangements, I wasn&#8217;t able to catch Eric Meyer&#8217;s opening keynote on the first morning of @media 2006 as I&#8217;d hoped. A podcast of the keynote is now available, so I took the opportunity to catch up
            on what I&#8217;d missed. You should too. Eric&#8217;s presentation looks back over the last 10 years of the evolution of CSS &#8211; which is far more interesting than it may initially sound, I promise. I guess the recurring theme is that
            of community involvement and shared knowledge. The history of CSS and modern web development is peppered with instances of individuals making discoveries, having innovative ideas and engineering clever work-arounds to found problems and implementing
            and sharing that knowledge for the benefit of the industry as a whole. I guess the classic example of this is the story behind the invention of the Box Model Hack. Jeffrey Zeldman had problems with a particular bug, the end result of which
            was that it wasn&#8217;t&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=297">Joining Yahoo!</a></h2>

        <p class="excerpt">&hellip;This week I started working for Yahoo!, as seems to be the fashion these days. I&#8217;ve joined Chris Heilmann, Stuart Colville, Mike Davies, Norm Francis and a whole bunch of other talented and clueful web developers in Yahoo! Europe&#8217;s
            London office, tucked away nicely at the edge of Covent Garden. I have to say I&#8217;m pretty excited to be joining a company that seems to really get it when it comes to the web &#8211; from my perspective, the fact the Yahoo! is currently
            the biggest publisher of microformatted data says a lot. Obviously, I&#8217;ve been hearing an awful lot of criticism, since talking to people about my move, that Yahoo! is apparently trying to hire most of the UK standards-aware development
            community. This is something I&#8217;ve had to think carefully about when considering my decision to join. Ultimately, I&#8217;ve failed to find a compelling argument as to why it&#8217;s bad for Yahoo! to be hiring lots of well-known developers.
            From the&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=304">24ways Returns For 2006</a></h2>

        <p class="excerpt">&hellip;Call me mad, but your favourite web geek advent calendar is back for a second season at 24ways.org. The idea is that we post a new web <em class="keyword">design</em>/development article every day from the 1st December all the way up to
            Christmas. Last year was tough work but well worth it as all the articles were very well received. I can&#8217;t promise we&#8217;ll top the success of last year, but at the very least we&#8217;ll try to match it. I&#8217;ve got a great line-up
            of authors all ready to go, including some familiar names from last year as well as some fresh contributors. I&#8217;ll not spoil the surprise &#8211; you&#8217;re going to have to check back each day and see what we&#8217;ve got in store.
            To kick the proceedings off today, I&#8217;ve opened with an article on building a widget like Safari RSS&#8217;s article length slider. This enables the user to dynamically adjust the length of text shown on the page. I&#8217;ve called it
            the Tasty Text Trimmer for want of a better name. Feel free&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=305">Changes Afoot at WaSP</a></h2>

        <p class="excerpt">&hellip;I don&#8217;t remember exactly when it was that Jeffrey Zeldman dropped me a line and asked if I&#8217;d join the Web Standards Project to help form their first task force. I guess it was some time in 2001 &#8211; I&#8217;d need to dig
            a lot of mail out of the archives to find exactly when. Together with Rachel Andrew we formed the Dreamweaver Task Force and began working more closely with Macromedia on improving their product&#8217;s support for web standards. A couple
            of years later, wanting to get a bit more involved with core activity, I took on the vacant &#8216;press&#8217; role, wrote some ridiculous press releases, helped launch Browse Happy and eventually found out (almost by accident) that I&#8217;d
            been opted on to the Steering Committee. A year on and I took on the role of Strategy Lead. This week, along with the wonderful Kimberly Blessing, I took over from Molly and became Group Lead of the Web Standards Project. Yikes. It&#8217;s
            been five years or so, but it feels&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=310">The State of Textpattern</a></h2>

        <p class="excerpt">&hellip;This site is published using Textpattern, and has been for more than four years. In fact, save for a few of Dean Allen&#8217;s own sites, this is pretty much the longest standing Textpattern installation going. I jest not. A major reason
            for starting this site at all was to play around with this new toy Dean had given me to try out. Back then I was running PHP as a CGI, which exposed a number of compatibility issues and helped iron out a few problems long before Textpattern
            was released to the public. It&#8217;s not been a perfectly smooth journey. From the get-go this was always something Dean was working on his is limited free time, and releases would come in fits and starts. Even once Textpattern was released
            to the public, updates would sometimes be months apart. All for good reason, and security fixes were never neglected, but you know, months. Eventually, of course, the inevitable happened and Dean had to hold his hands up to really not having
            the time to work on Textpattern&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=316">Preparing for 24ways</a></h2>

        <p class="excerpt">&hellip;With December just around the corner, you can bet your bottom dollar (or even just your bottom) that I&#8217;m in the throes of preparing for yet another year of 24ways. Just as we&#8217;ve done since 2005, we&#8217;ll be serving up a
            new web <em class="keyword">design</em> or development article each day for the first 24 days of December. Consider it something like a geek advent calendar, except without the little doors. This year, we&#8217;re aiming to try something a
            little different with the comments. Comments on articles can be great, but sometimes they can add more noise than value. This is especially true if an article gains traction and is linked to in places like Digg or Slashdot, bringing in fresh
            readers without any context. Whereas in many places it&#8217;s not uncommon to see hundreds of comments per post, we&#8217;d really like to encourage an environment of well-considered commentary that actually adds something to the conversation.
            So how do we go about encouraging that? I think the first&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=321">Armadillo v3</a></h2>

        <p class="excerpt">&hellip;As much as I attempt to avoid navel-gazing meta-posts, humour me briefly as I announce that for the first time in more than three-and-a-half years I&#8217;ve updated the <em class="keyword">design</em> of my site. If you&#8217;re reading
            via a feed (and if you&#8217;re not, c&#8217;mon!) come take a look. As I said back in August 2004 when I last re<em class="keyword">design</em>ed I&#8217;m very much a developer rather than a <em class="keyword">design</em>er and so it&#8217;s
            not going to win any awards, but I do like to try and keep the place looking nice. Points of note One of my objectives apart form the visual refresh was to make good use of microformats from the ground up, so you&#8217;ll find the posts formatted
            with hAtom, as well as hCards and XFN all over the place. There&#8217;s more to do, but it&#8217;s a good start. A lot of what I write is fairly text-based technical stuff, so I wanted to include more images to try and makes the page more
            visually interesting. I enjoy photography and use Flickr a lot, so I&#8217;ve simply used a standard&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=326">Content Management Nightmares</a></h2>

        <p class="excerpt">&hellip;I&#8217;ve come into contact with a lot of different content management systems over the years, from the off-the-shelf to the handmade by pixies varieties. Apart from the almost universal truth that everyone hates their content management
            system, I&#8217;ve found them all to be remarkably different. From the basic to the complex to the complex-but-should-have-been-basic they&#8217;re all out there and most of them are dangerous. Whilst working in a <em class="keyword">design</em>            agency seven or eight years ago where I was building mainly ASP/VBScript projects, we were approached by a client to perform a re<em class="keyword">design</em> of their existing site. The site had originally been built by one of the very
            large <em class="keyword">design</em> agencies who, as was quite common at the time, had offices all over the world. Part of the re<em class="keyword">design</em> necessitated some changes to their custom-built ASP content management system,
            so we set about requesting the source code from the original <em class="keyword">design</em> agency. Whilst our client was based at an office in London,&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=327">Content Management Without the Killing</a></h2>

        <p class="excerpt">&hellip; Last week I had the pleasure of presenting once again at the London @media conference, this time on the subject of Content Management. It was the first time I&#8217;d run that particular presentation, and consequently I&#8217;d like to
            have spent less time on the introductory material and more on the latter half, but on the whole it was pretty well received. I&#8217;ve put the slides up on SlideShare, but they don&#8217;t tell much of the story on their own. Therefore, I&#8217;m
            planning to serialise some of the main parts of the presentation as a series of articles, over at edgeofmyseat.com. The first of those is 8 Features to Look For When Choosing a CMS, and unsurprisingly runs through a number of things to take
            into consideration when you&#8217;re making your next content management system <em class="keyword">design</em> or purchasing decision. Clearly, every project&#8217;s needs are totally different, so I&#8217;ve tried to focus on the main underlying
            features and attributes that should stand you&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=329">The Clangers' Guide to Microformats</a></h2>

        <p class="excerpt">&hellip;I had the pleasure of being able to attend Oxford Geek Night 7 last month to present a five minute microslot called The Clangers&#8217; Guide to Microformats. There&#8217;s not much you can cover in just five minutes, but my aim was to
            give a brief overview of the concept of microformats to those who may not yet be familiar with them. The Clangers was a BBC television children&#8217;s programme made in the late 1960s and early &#8217;70s which remained in heavy rotation
            right through to when I was growing up in the 1980s. These little pink crocheted space creatures would communicate in a rhythmic series of whistles, which would give us humans enough of the gist to be able to follow along, but didn&#8217;t
            really communicate any detail. My attempt was to liken this to how we communicate our content in HTML, which has enough semantics to give us rhythm and intonation, but none of the detail. Microformats, of course, provide that detail. The Clangers
            Guide to Microformats from drewm&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=331">What Brian Cant Never Taught You About Metadata</a></h2>

        <p class="excerpt">&hellip;Last month I had the pleasure of speaking at the Geek in The Park event up in Leamington Spa, here in the UK. Whilst the weather didn&#8217;t quite hold out in the way we&#8217;d hoped, the whole day was still good fun. The evening events
            took place under cover in a pleasant local half pub, half nightclub sort of place. On the bill was Jon talking about icon <em class="keyword">design</em>, and me talking about Brian Cant. Growing up in the 1980s, Brian Cant was a familiar
            figure in my childhood. He was the friendly face presenting Play School on the television, reading a story on the BBC&#8217;s Jackanory or narrating the classic stop-frame animated Camberwick Green, Trumpton and Chigley series. On the drive
            up to Leamington Spa, and admittedly rather too late, it occurred to me that having been working on the web for more than ten years, it&#8217;s reasonably likely that a good proportion of the audience would be younger than me and therefore
            miss the cultural reference. Ah well. Kids these days. As it&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=338">Supersleight jQuery Plugin for Transparent PNGs in IE6</a></h2>

        <p class="excerpt">&hellip;I never meant to become obsessive about getting PNG transparency working nicely in IE6. In the summer of 2003, I hit across a situation on a client project where what the <em class="keyword">design</em>er wanted required the use of PNG
            transparency. The script that came to hand to get this working in IE6 at the time was called Sleight, but that only dealt with applying the filter to IMG elements. My <em class="keyword">design</em> needed to do the same for CSS background
            images, so I hacked up a different version of the script for that purpose, called it bgSleight, and occasionally updated it. Back in late 2007, I gathered up the work I&#8217;d been doing on bgSleight along with updates from Aaron Boodman&#8217;s
            original Sleight script and wrote Transparent PNGs in Internet Explorer 6 over at 24ways. In the article I go into some depth about the issues and the pitfalls of using an IE filter, so it&#8217;s a useful background read. Included with the
            article was a script I called SuperSleight which attempted to wrap up both my work&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=339">Easing The Path From Design to Development</a></h2>

        <p class="excerpt">&hellip;Earlier this month, I ran a half day workshop at Future of Web <em class="keyword">Design</em> London on the subject of easing the path from <em class="keyword">design</em> to development. The premise was that lots of people experience
            difficulty and even conflict at this point in projects, which can cause substantial derailments. As a company who work providing development services to primarily <em class="keyword">design</em> agencies and startups, this is an area we deal
            with day to day, and I think one that we&#8217;re pretty good at making as smooth as possible. So I was pleased to put something together on this subject when the guys at Carsonified asked if I could run a workshop. At 3.5 hours, there&#8217;s
            a lot of material which doesn&#8217;t make much sense as a deck of slides without the commentary. I had over 600 slides. Instead of putting all those up on slideshare, I figured it would be more useful to publish the outline I created the
            slides from. Outline: Easing the Path from <em class="keyword">Design</em> to Development Thanks to the guys at Carsonified for asking&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=343">The Fallacy of Page Zooming</a></h2>

        <p class="excerpt">&hellip;A couple of weeks ago, Cameron Moll posted an article entitled Coding like it&#8217;s 1999 in which he put forward his case for switching back to using HTML4 and sizing his text in pixels. I&#8217;m not going to cover the HTML issue today
            (although I happen to disagree with Cameron&#8217;s choice), but I did want to put some thoughts down on the issue of sizing text in pixels. The argument that many <em class="keyword">design</em>ers put forward is that working in relative
            sizes (such as percentages or ems) is hard work because you have to take inheritance into account. In fact, Cameron refers to it as the &#8220;burden of calculating relative units throughout a CSS document&#8221; in contrast to &#8220;the
            convenience of absolute units&#8221;. I can absolutely see his point on a surface level. However, I see no reason to use pixel-sized text, and in fact I think it&#8217;s shooting yourself in the foot to do so. The approach I take is to size
            the body element in ems, and then use percentages from that&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=344">Own Every Aspect of The Design</a></h2>

        <p class="excerpt">&hellip;Most of the projects I work on are for <em class="keyword">design</em> agencies &#8211; they <em class="keyword">design</em> how the site or web app should look, and then bring it to us to attach the electrodes, crank up the power and
            bring their creation to life. One thing that every project has in common is that there&#8217;s always a bit more to be <em class="keyword">design</em>ed than is apparent at the surface level. Even a simple five-page brochure site has more
            to think about than the layout and content of the five main pages. There&#8217;s things like the site map, accessibility statements and legal pages. If your site has forms &#8212; even a simple contact form &#8212; you need to think about
            the messaging around it. What does the user see when the form has been completed? What&#8217;s in the email that is generated? The reality is that in most cases there are lots of details that don&#8217;t get planned in right from the start
            and end up being implemented by a developer. Perhaps by me. No matter how conscientious the developer, they&#8217;re&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=347">Moving from Basecamp to ActiveCollab</a></h2>

        <p class="excerpt">&hellip;At edgeofmyseat.com we do most of our work without meeting, and for a lot of the time without out physically talking to our clients. Certainly once a project&#8217;s underway, day to day interaction occurs online. With multiple projects
            in some stage of active development at any one time, and lots of messages being fired off between multiple team members, if we tried to do this by email it would quickly become unmanageable. Enter Basecamp As a solution to this we use Basecamp
            as a project management and collaboration tool between us and the client. There are pretty much just two things it does well for us: keeping conversations organised and archived, and maintaining a centralised collection of project files (such
            as <em class="keyword">design</em> files, specs, and so on). Just recently we hit up against our account limit for active projects and so have been faced with the option to close down some projects (which isn&#8217;t really an option) or upgrade
            the account. We use Basecamp pretty much all day&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=349">The Curse of max_file_uploads</a></h2>

        <p class="excerpt">&hellip;Today marks a year since we shipped the first version of Perch, and we celebrated by putting out another big release. We&#8217;ve been following a strategy of shipping medium-sized updates regularly throughout the year (July, October,
            December, February), each time fixing any issues that users have reported and always adding some new functionality to make it worth the trouble of updating. This latest release has been a big one. We&#8217;ve reflected that in the version
            number, jumping from 1.2.6 to 1.5. As well as the usual fixes and features, we&#8217;ve added an entire developer API enabling the extension of Perch through apps. The first app we&#8217;ve launched with is for the creation of new pages. One
            bug that cropped up late in the development cycle had to do with a change to PHP that caught us by surprise. PHP 5.2.12 had added a new INI directive called max_file_uploads, <em class="keyword">design</em>ed to prevent DOS attacks. The supposed
            attack would work by uploading a huge number of files to a&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=350">Launch Week</a></h2>

        <p class="excerpt">&hellip;I&#8217;m in the fortunate position these days of being able to see lots of my work go live all the time. We work on lots of projects for a whole range of clients, and we&#8217;re shipping stuff constantly. That&#8217;s great, but what&#8217;s
            even better is when it&#8217;s your own projects that you&#8217;re shipping. This week (and it&#8217;s only Tuesday) has been a mammoth week for launching some of the stuff we&#8217;ve been working on lately. First up, yesterday we shipped
            a new version of our little CMS product Perch. Version 1.6 includes lots of big new features, many of which are centred on improving user confidence when making edits to their sites. Lots of the end users who wind up using Perch are small
            business owners, administrators, club secretaries, all the sort of people who easily might not be that confident using online software. So we focussed on making them more comfortable. We added multi-level undo, save-as-draft and content preview.
            We also did some interesting&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=354">Ideas of March</a></h2>

        <p class="excerpt">&hellip;When I started this site in 2003 &#8212; as best as I can tell it was 2003 &#8212; a individual&#8217;s personal site or blog was pretty much their primary method for joining the online conversation. If you had something you wanted to
            share, you wrote a blog post. Others would read it, and if they found it to be of value they might link to it in a post of their own. Or leave a comment. That&#8217;s how we all communicated. At that time there was an amazing wealth of content
            being posted to blogs, and truthfully, it was the primary way I picked up information around the subject of web <em class="keyword">design</em>, and spurred me to form my own opinions on subjects I wouldn&#8217;t have otherwise thought about.
            Because you can&#8217;t blog without an opinion. One thing I&#8217;ve found over the last four-and-a-half years of using Twitter (where did that time go?) is that the opinions and ideas that I used to consider for a while and then focus into
            a blog post now get fired off into a 140 character tweet&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=357">The Lure of On-page Editing</a></h2>

        <p class="excerpt">&hellip;I get asked quite often why Perch doesn&#8217;t offer any sort of on-page editing. It&#8217;s something we&#8217;ve given a lot of consideration to, and as it&#8217;s an interesting software <em class="keyword">design</em> issue I thought
            I would document some of my reasoning here. So what do I mean by on-page editing? In the context of a content management system, we&#8217;re talking about the ability to make edits to a page directly by clicking on the content (or a nearby
            Edit link) and manipulating it in place on the front end of a website. The alternative approach in contrast to this &#8212; and the approach we currently take with Perch &#8212; is for the user to go to a dedicated control panel to edit the
            content away from the page. There are a couple of issues with on-page editing in my mind. The technical The big technical hurdle with on-page editing is the necessity for the CMS to inject its UI into the front-end page. At first that doesn&#8217;t
            sound too bad, but the more you think about it, the&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=358">The Best Forms Implementation I've Ever Built</a></h2>

        <p class="excerpt">&hellip;The one thing that will really kick your developers&#8217; butts when building an interaction-heavy web app or site is the forms. Forms can be a lot of work to implement. Get the technical <em class="keyword">design</em> of your form generation/handling/validation
            system right and your project can fly along. Get it wrong, and you&#8217;re sunk in work that becomes tedious and demotivates everyone involved. Now, before you tell me that this is a non-issue because no one builds individual forms anymore
            and that they&#8217;re all auto-generated by frameworks, I&#8217;m talking about the bit that goes on inside the framework. My consideration is how you <em class="keyword">design</em> a system that outputs forms without resulting in a sucky
            literal representation of a database row in HTML. Anyone who cares about interaction <em class="keyword">design</em> and gathering accurate data carefully <em class="keyword">design</em>s and tunes forms individually to suit the task in hand.
            Auto-generated data entry forms are fine for routine back-office jam-this-data-in-a-database-table tasks,&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=361">How To Make Your Website Fast</a></h2>

        <p class="excerpt">&hellip;Since launching the new Greenbelt website this week, one thing a lot of people have commented on and asked about is the speed. It&#8217;s noticeably fast. I&#8217;ve never heard someone complain that they really like a site, but goshdarnit
            if it weren&#8217;t so fast. Fast beats slow, every time. So we wanted to make it fast from the outset. That said, boring doesn&#8217;t beat fast, and neither does not reflecting the brand. Greenbelt Festival is a buzzing, vibrant event. It
            also has a strong identity developed by our <em class="keyword">design</em>er on this project, Wilf Whitty at Ratiotype. A craigslist-style non-<em class="keyword">design</em> wasn&#8217;t going to cut it, no matter how fast that may be. As
            a result, the site is full of big photos and iconography, even video and audio. And it&#8217;s still fast. I don&#8217;t even remotely claim to be any sort of authority on the subject, but I can tell you what worked for us. Start with good
            hosting It frequently surprises me how little some <em class="keyword">design</em>ers and developers appear&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=362">Why Use a Database With a Small CMS?</a></h2>

        <p class="excerpt">&hellip;As the lead developer of the small CMS Perch, I&#8217;m often asked why we use a database at all, when Perch is aimed at smaller websites. There seems to be an assumption that using a relational database like MySQL is both complex, and
            somehow &#8216;heavier&#8217; than needed for a &#8216;lightweight&#8217; solution. I wanted to talk a bit about both these issues, as the misunderstanding is pervasive and can lead to poor choices if you&#8217;re not careful. Databases are
            hard to use When learning HTML, every budding web <em class="keyword">design</em>er soon wants to start working with images. The problem is, images on the web are complex. You have to learn about the different formats (JPEG, GIF, PNG, SVG&#8230;)
            and when to use each. You need to learn about scaling images to the appropriate size, and exporting from your graphics tool in a way that optimises for file size. You even need to understand some basic conventions about file naming and, when
            it comes to adding the tag to your page, file paths.&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=363">24 ways and Perch 2.1</a></h2>

        <p class="excerpt">&hellip;When I launched 24 ways in 2005, it was pretty much a last-minute project. To get the site live quickly, I just reached for the blogging system Textpattern, as I was familiar with it. Textpattern did a good job managing articles, comments,
            RSS feeds and so on, but for one reason or another development stagnated. Textpattern&#8217;s flexibility enabled me to implement some custom features as plugins (like the day-by-day navigation down the side of the article pages) but basic
            features like comment spam detection were causing problems. Replacing a CMS isn&#8217;t usually a fun job, so I carried on with Textpattern for longer than perhaps I should have. Fast forward to 2012, and we now have our own CMS, Perch. I&#8217;m
            currently working Perch 2.1, and so it made sense to rebuild 24 ways using it and at the same time test the new features I&#8217;ve been working on. Rebuilding the site with Perch took about a day, and migrating the content took another day
            on top of that. Improving&hellip;

        </p>
        <p class="source"></p>
    </li>

    <li class="">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=366">Rebuilding 24 ways</a></h2>

        <p class="excerpt">&hellip;As those with long memories may recall, I first launched 24 ways in December 2005 as a fairly last-minute idea for sharing a quick tip or idea every day in advent. I emailed some friends to ask for contributions, and was overwhelmed by
            the response. Instead of the tips I&#8217;d had in mind, what I got back was full-blown articles prepared with depth and care. I <em class="keyword">design</em>ed (and I use the word lightly) the site myself, got it up and running using blog
            software, and off we went on a twenty-four day roller coaster. The site was such a success that we repeated the process in 2006. When recruiting authors for our third year in 2007, Tim Van Damme asked me to do something about the terrible
            <em class="keyword">design</em>. I pretty much said &#8220;well, go on then!&#8221; and that year we launched with an all-new look. Tim did an amazing job with a <em class="keyword">design</em> that was well ahead of its time, both visually
            and technically. It&#8217;s hard to remember now, but the heavy use of RGBA colour meant that the <em class="keyword">design</em> only&hellip;</p>
        <p class="source"></p>
    </li>

    <li class="odd">
        <h2><a href="/perch/addons/apps/perch_blog/edit/?id=367">Why is Progressive Enhancement so unpopular?</a></h2>

        <p class="excerpt">&hellip;A little earlier today, having read how Sky broadband had blocked the jQuery CDN I tweeted Sky broadband erroneously blocks http://t.co/5i7EXxYlDy and that’s why we don’t depend on JavaScript, kids.— Drew McLellan (@drewm) January 27,
            2014 To which many responded this is why we don&#8217;t rely on CDNs and how you can (shock, horror) even host your own JavaScript fallback and how you make a hole at each end of the shell and suck with a straw. In order to clarify the problem,
            I followed up with What the Sky/jQuery thing teaches us is that unpredictable factors can cause good JS to fail. Plan by <em class="keyword">design</em>ing pages to work without first.— Drew McLellan (@drewm) January 27, 2014 The internet,
            as a network, is <em class="keyword">design</em>ed to be tolerant of faults. If parts of the network fail, the damage gets routed around and things keep working. HTML is <em class="keyword">design</em>ed to be tolerant of faults. If a document
            has unrecognised tags, or only partially downloads or is structured weirdly, the browser will do its&hellip;</p>
        <p class="source"></p>
    </li>

</ul>
<ul class="search-results">

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=37">Upgrades immanent</a></h2>
            
            <p class="excerpt">&hellip;It looks as though Dean is close to releasing the next beta of Textpattern, the content management system on which this site is run. I&#8217;ll probably hold off for a couple of days to see if anyone has any major problems, and then upgrade. Expect outages &#8211; they will happen. It&#8217;s a beta, baby.

Also due for an upgrade is Apple&#8217;s iPod according to Think Secret.

In other news, http://www.welovetheiraqiinformationminister.com/.&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=40">Web users don't read</a></h2>
            
            <p class="excerpt">&hellip;I read Derek Powazek&#8217;s <em class="keyword">Design</em> for Community quite some time ago when it first hit the shelves. I&#8217;ve always admired Derek&#8217;s sites, and consider a visit to ({fray} tell your stories) to be pure indulgence.

I&#8217;m involved in building community sites myself these days, so have been re-reading selected parts of Derek&#8217;s book. It was only today that I came across this article on the book&#8217;s companion site. Words of truth, eloquently spoken.&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=42">On the subject of RSS</a></h2>
            
            <p class="excerpt">&hellip;In today&#8217;s Daily Report, Jeffrey Zeldman weighs up some of the pros and cons of personally published sites offering a syndicated news feed.

Having recently started using and publishing in RSS, I felt that there was more to the discussion that Jeffrey was letting on. I needed to make clear my own opinions on the matter. It&#8217;s disagreeing with someone that does that.

I monitor a number of personal sites via their syndicated newsfeeds. The ones I keep an eye on are typically the ones that are updated frequently (maybe once or twice a day), that I typically wouldn&#8217;t have the time to read otherwise. Without visiting each site in turn, I can quickly see who has posted new content, scan-read the new post, and if it&#8217;s interesting I hit Enter and the site itself opens in a browser window. (Reading direct from a newsreader is dull as rocks).

This works well for me because I can find the content I&#8217;m interested in quickly, and then still enjoy that content to its&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=50">The people's web</a></h2>
            
            <p class="excerpt">&hellip;I&#8217;m involved in a whole load of different online groups and lists where people (often newbies) ask questions about web <em class="keyword">design</em> and development. The usual occurrence is that someone will ask a question and they will get an answer to their question and a description of what is wrong with what they&#8217;re doing. I have to admit I do this too.

What&#8217;s up with us? This has to be wrong.

I&#8217;m very passionate about building a better web. I strongly advocate the use of web standards and general good practices. I can get anal about it at times. The worst thing of all is that I do it in the face of those who are simply trying to get their content online. I&#8217;m risking coming down so heavy with what their doing wrong that it obliterates what they&#8217;re doing right &#8211; namely publishing their content on the web for others to share.

Taking a purest line, no one should publish anything on the web unless it is &#8216;clean&#8217; and &#8216;valid&#8217;. However,&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=65">Object, Echo, Tango</a></h2>
            
            <p class="excerpt">&hellip;Mark Pilgrim&#8217;s article The Vanishing Image: XHTML 2 Migration Issues over at XML.com takes a thorough look at Internet Explorer&#8217;s implementation of the HTML object element. Whilst being interesting reading from an XHTML 2.0 point of view, it also makes excellent accompanying reading to my Flash Satay article at ALA. (Hat tip: James Ellis)

Also worth a mention is The Echo Project, which I&#8217;ve been following for the last 10 days or so. The purpose of the project is to explore defining a new content syndication, publishing and archiving format, independent of any particular vendor, for the free use of the community. The planning is all going down on Sam&#8217;s Wiki, and comments are invited from anyone who has a valuable contribution to make. It&#8217;s very interesting reading, and a worthwhile project to give support to. 

Mike Jones at Footnote* Consulting has relaunched their site this week. If you&#8217;re a <em class="keyword">design</em> or development outfit looking for some overflow&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=78">Oh look ...</a></h2>
            
            <p class="excerpt">&hellip;Anyone recognise the <em class="keyword">design</em> of this site? It reminds me of something, but I can&#8217;t quite place it. This was discovered courtesy of an interesting looking blog I can&#8217;t read. Can anyone translate?

Unrelated, look what comes up when you go to Google and search for find a guy. Google adjusts its results constantly, but at the time of writing, this site is coming up as the number 1 result.

(Can you tell I&#8217;ve been searching through my referrer logs?)&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=81">Usability on the cheap</a></h2>
            
            <p class="excerpt">&hellip;The Register reports on the new UK government Illustrated Handbook for Web Management Teams launched last week. Despite some questionable impositions like the mandatory use of frames on homepages and would-you-believe-it the requirement to use HTML 4.01 to ensure compatibility with all browsers, (Have you found a browser yet that won&#8217;t happily digest carefully written XHTML?) the framework is generally well meaning and offers reasonable advice. 

One suggestion within the document is to save money on usability testing by getting students and family involved. I can see how that is actually a great idea for certain sites that are working to a budget, but if those people aren&#8217;t your target audience you can&#8217;t make them pretend that they are. In usability testing you need simple, honest reactions. Anything else and you&#8217;re kidding yourself.

It&#8217;s not the most coherent of documents, not is it technically accurate to the extent it should be, but it would seem&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=88">Attention Fireworks and Photoshop users</a></h2>
            
            <p class="excerpt">&hellip;To all Fireworks and Photoshop/ImageReady users:- Go ahead, <em class="keyword">design</em> you sites in a professional image manipulation program. That&#8217;s a good thing to do. It helps with layout, it helps in defining a specific look and feel, it gives you control and creative freedom all in an environment built for the task. But: keep the hell away from the automatic HTML export features.

Repeat after me: &#8220;No matter how good my intentions, automatic slicing and dicing does not a good website make&#8221;.

To the following files:- transparent.gif, shim.gif, spacer.gif, pixel.gif. I ended our relationship more than two years ago. Please stop contacting me like this. I do not wish to see you again. You were to me but a last resort &#8211; and I truly believe that&#8217;s all you will ever allow yourself to be. Please respect my feelings and leave me alone.

To the head chef:- This week I had the misfortune to sample your Tag Soup. It was foul tasting and left me feeling somewhat nauseous. Many high&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=89">Re-Useit Design Contest</a></h2>
            
            <p class="excerpt">&hellip;Today Bob Sawyer announces the Re-Useit <em class="keyword">Design</em> Contest. The name of the game is to re<em class="keyword">design</em> Jakob Nielsen&#8217;s useit.com. 


	<em class="keyword">Design</em> a usable, intuitive layout and navigation, organize the content with usability in mind, and create a work of art which still reflects the importance and influence of Nielsen&#8217;s work. 


Basically, it&#8217;s a chance to show that usable <em class="keyword">design</em> isn&#8217;t necessarily dull <em class="keyword">design</em>, and what better way to demonstrate it. Bob has asked me to sit on the judges panel for the contest, so I&#8217;m looking forward to seeing the results.&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=102">The times they are onchanging</a></h2>
            
            <p class="excerpt">&hellip;Browsers are getting better all the time. Those being worked on in the open source community like the Mozilla family of products are getting better every day. Add to that browsers like Apple&#8217;s Safari (which is based on the open source KHTML rendering engine) and the collective browsing experience is just getting better and better. Even Internet Explorer hasn&#8217;t been left too far behind with companies like Google developing free add-on toolbars offering functionality such as pop-up blocking.

One feature a lot of browsers seem to have (and offered by the Google Toolbar for IE) is Form Autofill. This useful utility allows you to enter a common set of information such as your name, email address and country, and then have the browser automatically fill out form fields based on that data. A real timesaver. But &#8230;

As web <em class="keyword">design</em>ers/developers we need to be careful. Typically, (I haven&#8217;t found one yet) form auto-fill features can behave a little unpredictably with the&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=104">Dear Apple Computer</a></h2>
            
            <p class="excerpt">&hellip;Congratulations on the launch of your new PowerBook range. Yet again, you have paved the way with cutting edge <em class="keyword">design</em> and innovation.

Please would you consider making a gift to me of a 15inch PowerBook. I would put it to exceptional good use, and would tell everyone how great it is. I would gladly buy one myself, but I am a sorry mess.

Please don&#8217;t consider this to be begging. I am not begging. I am offering you a unique marketing opportunity, a sponsorship opportunity, the opportunity for tremendous positive publicity in the struggling UK market, and also I want one really really badly.

I look forward to your response with eager anticipation.

Yours,

Drew McLellan

P.S. Pleeeeease!&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=107">The IC-Style</a></h2>
            
            <p class="excerpt">&hellip;According to Joe Clark I am a perpetrator or what he calls The International Compliant Style of site <em class="keyword">design</em>. I&#8217;m not sure how to take that. I guess to be cited as an example means that I have executed my <em class="keyword">design</em> style well. My site is in the IC-Style, not emulating it. That has to be good.

On the flip side, Joe is saying that my <em class="keyword">design</em> is a mass-produced unoriginal. That said, simple, clean, easy-to-read and &#8216;less is more&#8217; are hardly original concepts, so I&#8217;m pretty happy in my unoriginality. The vast majority of sites that try to be avant-garde (like the Flash examples Joe cites) fail to make good on their intentions and end up obscuring their content in the process. I know I don&#8217;t have the <em class="keyword">design</em> skills to be able to pull off a really usable, visually stunning <em class="keyword">design</em> and besides, that&#8217;s not what my site is about. That&#8217;s not what you&#8217;re here for.

So I guess I&#8217;m happy in my IC-Style. At least if I&#8217;m going to be part of this&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=119">It's just this damn XML</a></h2>
            
            <p class="excerpt">&hellip;I started working on a nice little personal project in PHP. It has a specific real-world use, and in evaluating the approaches I could take with the <em class="keyword">design</em>, I decided that it didn&#8217;t need a database. Rare for me. I like databases. The only data this application needs to store is general system configuration settings, which I thought would be best stored as a simple XML file. I like XML &#8211; much more than databases.

So I began carrying out proof-of-concepts on each of the major parts of the project. I searched on the excellent php.net for the XML functions, and found them. Hmm.

Why is PHP&#8217;s XML implementation so crap? How has it managed this long without DOM support? I can see it&#8217;s on its way, but how has everyone been managing? Do PHP developers not care about XML?

I&#8217;ve settled with parsing my XML file out into an array of arrays (yuk), which is useable but hideous and putrid. I think I&#8217;m going to have to <em class="keyword">design</em> my application in such a way as when&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=128">ReUSEIT judging underway</a></h2>
            
            <p class="excerpt">&hellip;So the ReUSEIT contest has closed for new submissions, and the judging has commenced. I can&#8217;t comment on the entries, other than to say that there has been some excellent work done. Everyone who took the time and entered deserves recognition for their achievement.

For me as a judge, this raises issues. Whilst I know attractive <em class="keyword">design</em> and good quality code like the back of my hand, one of the primary objectives for this contest is usability <em class="keyword">design</em>. I can tell you what bad usability looks like. Bad usability is usually accented by grunts of desperation and another trip to the coffee machine. Good usability, on the other hand is transparent.

As it happens, judging usability with an A/B comparison is easy. Suddenly the plus and minus points leap off the page at you much more readily then they do when looking at a single page in isolation. So here&#8217;s a tip for today: when attempting to assess the usability of a site you&#8217;re working on, compare it to something similar&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=129">New job</a></h2>
            
            <p class="excerpt">&hellip;So the dot.com work came to an end (as dot.com work does), and yesterday I started work at a new place. I&#8217;m back in my natural habitat of a <em class="keyword">design</em> agency, and working again with my old friend Mr Pitman, which is splendid. I won&#8217;t link to our website yet, as I&#8217;m about to start building a new one (the current site is pretty old and doesn&#8217;t do the company justice), so there&#8217;s something to look forward to.

On an unrelated note, today is Guy Fawkes night here in merry old England. There are fireworks going off everywhere &#8211; the sky is alight. Both Rachel and Mike are getting particularly grumpy about it all, which in itself is rather amusing.&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=136">Application Interface Design</a></h2>
            
            <p class="excerpt">&hellip;Over at Digital Web Magazine this month, Jean Tillman from Unisys discusses an issue close to my heart &#8211; User Interface <em class="keyword">Design</em> for Web Applications.

Whilst the article is refreshing in its subject matter (you don&#8217;t hear a lot of talk of AUI <em class="keyword">design</em> online), there are quite a few specific practical points in the article that I disagree with. For the last three years or so, my 9 to 5 (and quite a lot of my 5 to 9) has been taken up with specifically <em class="keyword">design</em>ing and building web applications &#8211; so on reading some of the points in Tillman&#8217;s article I felt the need to respond.


	A user might fill out the same form many times (for example, to add several user-IDs to the database), so it’s not important to distinguish which pages have been visited. In cases like this, it’s preferable to specify the same color for the unvisited links as for the visited links so all links look the same.


Whilst I agree that main functions within the application should not indicate a&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=137">Creating and Designing Your Own Personal Disaster</a></h2>
            
            <p class="excerpt">&hellip;In the BBC article Creating and <em class="keyword">Design</em>ing Your Own Print Ads, the author suggests that


	With the wide availability of computers and <em class="keyword">design</em> programs, it is now possible to be your own <em class="keyword">design</em> agency. With attention to detail you, too, can produce your own professional-looking advertisements.


With the wide availability of building materials I could build my own house, but that doesn&#8217;t mean it wouldn&#8217;t fall down. The suggestion that someone should try and produce their own print ads instead of focusing on their business and what they do best is absurd. Not only do you have the expense of buying additional software, you then have to learn how to use it and finally hope to goodness that you have a thimble of talent somewhere in your body. After much expense, several headaches and many many hours of hard work you might just get lucky and come out with something good. If your business doesn&#8217;t go bust in the mean time, you might just get away with it.

Alternatively, you&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=16">About</a></h2>
            
            <p class="excerpt">&hellip;Everyone has an about page. It&#8217;s how you know what someone&#8217;s all about. I&#8217;m all about the about. Mmm metadata. So here follows some of that, beginning with one of those awkward third-person biographies.



Awkward third-person biography

Drew McLellan has been hacking on the web since around 1996 following an unfortunate incident with a margarine tub. Since then he&#8217;s spread himself between both front- and back-end development projects, and now works as a Web Developer for edgeofmyseat.com in Maidenhead, UK. Prior to this, Drew was a Web Developer for Yahoo!, and before that primarily worked as a technical lead within <em class="keyword">design</em> and branding agencies for clients such as Nissan, Goodyear Dunlop, Siemens/Bosch, Caburys, ICI Dulux and Virgin.net. Somewhere along the way, Drew managed to get himself embroiled with Dreamweaver and was made an early Macromedia Evangelist for that product. This lead to book deals, public appearances, fame, glory, and his eventual&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=183">Web Standards Solutions</a></h2>
            
            <p class="excerpt">&hellip;If you&#8217;re the sort of person who follows developments in standards compliant <em class="keyword">design</em>, chances are you&#8217;ll be familiar with the work of Dan Cederholm of SimpleBits.com. Even if you&#8217;re not familiar with the name, you may recognize his work on the standards compliant re<em class="keyword">design</em>s of FastCompany and Inc.com, and his recent article for A List Apart. Over the past few months I&#8217;ve had the pleasure of working with Dan myself &#8211; I&#8217;ve been the Technical Reviewer for Dan&#8217;s new book. 

 Web Standards Solutions: The Markup and Style Handbook is a real solutions-orientated guide to using standards-based techniques in your daily work. Dan doesn&#8217;t just suggest what you should be doing when developing a site, but rather goes on to explain how to do it in real, honest and practical terms. The format of the book takes its linage from the SimpleQuiz features Dan runs on his site. That&#8217;s to say that each chapter starts of by posing a problem or <em class="keyword">design</em> issue,&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=186">Take-out Interfaces</a></h2>
            
            <p class="excerpt">&hellip;Ordering food over the phone can be tricky. Typically all the best take-out places are run by folk who learned their craft in distant countries and for whom English is not their first language. Add to that the noise from busy kitchens and a selection of hard-to-pronounce dishes, and placing an order can be a real nightmare. Not to mention the fact that I&#8217;m a geek, and by my very nature I hate using phones at the best of times. (Who knows how to work those things anyway?)

I have, however, been very impressed with how my local Chinese take-out place has focussed its efforts on making orders easy to place. They&#8217;ve carefully considered and <em class="keyword">design</em>ed the customer interface and made optimizations in a number of key areas.

First off is the menu itself. Every item on the menu has a number as usual, but at the bottom of each page is a specific instruction &#8211; Please order by number.  By making numbers the default mechanism for placing an order, they let the customer off the&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=189">Defensive Design for the Web</a></h2>
            
            <p class="excerpt">&hellip;I&#8217;m usually the first person to quote the mantra that no software is bug-free, especially as I&#8217;m usually the one who&#8217;s written the code, but the inescapable fact holds true that if something can go wrong it will, and that bugs will be found by the end user no matter how much testing you do. In real-life systems (like shops and restaurants) if something unexpected happens, the people involved just adjust to cope. We&#8217;re human beings capable of intelligent thought and able to adjust our actions based on whatever comes our way. The show must go on.

 In contrast to human beings, the software we use on a daily basis is completely deterministic. The flow of the program can be logically followed, including any choices made based on the users input. That&#8217;s essentially how software works and how it&#8217;s written. For software to cope with different situations the developer has to preempt what those situations might be and to code responses to them. Considering&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=193">Icons for Web Applications</a></h2>
            
            <p class="excerpt">&hellip;Some people are really good at <em class="keyword">design</em>ing icons. However, those of us from Earth find it tricky to say the least. This is a shame, as a web application can be made or broken by the quality of its interface and currently a major part of any interface is its icons. So what&#8217;s a girl to do?

You can try <em class="keyword">design</em>ing your own. It&#8217;s at this point you realize that 16&#215;16 pixels isn&#8217;t so big. You quickly find that anything detailed comes out as a blob, and anything simple comes out as a blob. Unless you&#8217;re looking to <em class="keyword">design</em> an icon for the user to invoke the blob command, you&#8217;re somewhere short of your goal. So you decide to get outside help.

You try to find a freelancer or contractor to <em class="keyword">design</em> some icons. Any freelancer or contractor you ask will claim that they can <em class="keyword">design</em> icons. Every freelancer or contractor will deliver you a collection of 80 icons for invoking the blob command.

Face it. Unless you have someone on your team who is the bastard child of&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=195">Page 23</a></h2>
            
            <p class="excerpt">&hellip;Keith told me to:


	Grab the nearest book.
	Open the book to page 23.
	Find the fifth sentence.
	Post the text of the sentence in your journal along with these instructions.


From a book called Defensive <em class="keyword">Design</em> for the Web by 37signals:


	This poor messaging is bound to create further confusion.


Well, quite.&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=203">Writing The Code is the Easy Bit</a></h2>
            
            <p class="excerpt">&hellip;Software <em class="keyword">design</em> is hard. Yeah, I know no one said it was easy, and it&#8217;s certainly a lot of fun, but damn it&#8217;s hard. I&#8217;m currently working on a PHP/MySQL based content management system, largely based on the lessons I learned after spending the best part of a year building an ASP/SQL Server based CMS for a different company. But you know what? The decisions don&#8217;t get easier with experience, they get harder.

When building a system that is going to be used by real life users (who have paid you money and know how to use a telephone) you learn an awful lot about your products very quickly. You find out what sort of things the users want to do that you hadn&#8217;t anticipated, and you learn what features are going to be requested. You also learn the limitations of your architecture and framework, and before too long you can begin to curse those decisions that you made early on.

They say ignorance is bliss &#8211; and that&#8217;s certainly true when it comes to&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=204">Experience is More Important than Knowledge Of Syntax</a></h2>
            
            <p class="excerpt">&hellip;I&#8217;m still pretty much learning PHP. Having a lot of experience in ASP, and going back further, perl, stands me in excellent stead. Over the years I&#8217;ve taught myself a number of different languages, starting with BASIC when I was roughly seven years of age, so I&#8217;m pretty comfortable with reading technical documentation and gleaning the information I need. After all, when <em class="keyword">design</em>ing a web application (as I&#8217;ve noted previously) it&#8217;s the logic that is key, rather than the code. Code can be looked up.

What you can&#8217;t gain from the manual, however, is the lessons learned from experience. The user comments on PHP.net give a snapshot of various peoples&#8217; experiences, but it&#8217;s incredibly hard to learn from other peoples&#8217; mistakes when it comes to code. The manual can tell you how to use each aspect of the technology, but it won&#8217;t tell you what&#8217;s best to use in each precise circumstance. There are some things you just have to learn&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=212">And Breathe Out</a></h2>
            
            <p class="excerpt">&hellip;PHP has been giving me the run-around. Just when you think you&#8217;ve got it all sussed out it springs another surprise. It likes to play with me that way &#8211; show me who&#8217;s boss.

This afternoon Nathan and I launched a site we have been working on for months. More accurately, we launched a site based on the content management system we&#8217;ve been working on for months. She flies! Hurrah and all that. Up until the site going live today I&#8217;d been validating pages using one or other of two methods. The first thing I tried was installing the W3C validator on my dev server. That almost worked, but no matter what input I gave it seemed to be resolving paths to the wrong site. I don&#8217;t think it liked by VirtualHosts set up. Being too pressed for time to really fiddle with it, I resorted to saving the output of a view source to disc and uploading the file to the W3C service. This worked fine.

On enlivening the site this afternoon, I took the opportunity to run the&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=213">Scalability vs Performance</a></h2>
            
            <p class="excerpt">&hellip;When <em class="keyword">design</em>ing the architecture for a web application, it is normally desirable to <em class="keyword">design</em> every aspect of the system to be as scalable as possible. It&#8217;s only too often that badly <em class="keyword">design</em>ed apps have need to be completely refactored before any further development work can be done, entirely due to an unscalable architecture. If the app hasn&#8217;t been <em class="keyword">design</em>ed with an attitude of what if we wanted to &#8230;? then adding a dot-dot-dot six months down the line can be a massive undertaking with needless slaughtering of otherwise good code.

But we know this; we know that applications, any code in fact, needs to be <em class="keyword">design</em>ed to cope effectively with change. It&#8217;s one of the principals behind OO and it&#8217;s generally accepted as A Good Thing. This is typically done through the use of OO <em class="keyword">design</em> principals closely coupled with various levels of abstraction. The question it raises, however, is where do we stop? At what point does multiple levels of abstraction stop saving&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=227">Web Development is Software Development</a></h2>
            
            <p class="excerpt">&hellip;With a considerable amount of the world&#8217;s web development being performed in a context focussed on visual <em class="keyword">design</em>, it&#8217;s easy to see how that work can get pushed to the side a little. That&#8217;s not to say that the importance of development work isn&#8217;t recognised, but perhaps that the nature of the work isn&#8217;t recognised for what it is. Within the context of a web shop or <em class="keyword">design</em> agency the tendency is to approach development aspects of a project in the same way as the <em class="keyword">design</em>. However, development is not the same as <em class="keyword">design</em>, and the processes and management of such work has to reflect this. 

When all is said and done, web development is a flavour of software development. Of course this is both a blessing and a curse. Recognising your projects as software development means enacting all sorts of formal processes and procedures, and having to worry about nasty stuff like specification documents, bug tracking and team structure. The upside to this is that the software&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=236">CSS Anthology</a></h2>
            
            <p class="excerpt">&hellip;Rachel&#8217;s got a new book out aimed at anyone who uses CSS on a daily basis to just get stuff done. The CSS Anthology: 101 Essential Tips, Tricks and Hacks answers a succession of those quick how do I &#8230;? questions that constantly crop up when working with CSS in a production environment.

The publishers, well respected web <em class="keyword">design</em> and development resource site SitePoint say the following:


	The CSS Anthology: 101 Essential Tips, Tricks &amp; Hacks’ is ideal for  experienced Web <em class="keyword">design</em>ers who would like to add sparkle to their existing <em class="keyword">design</em>s,  as well as newcomers who want to learn Web <em class="keyword">design</em> the right way the first time.



	The book is written so that it can be read cover to cover, or referred to like  a cookbook with 101 different recipies for your Website. It&#8217;s written in an  easy-to-follow, consistent  format that&#8217;s well illustrated with plenty of screenshots and code examples, providing  quick visual cues. If you hate wading through dry academic-style&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=237">Supermarket Usability</a></h2>
            
            <p class="excerpt">&hellip;It&#8217;s an undeniable fact that supermarkets are <em class="keyword">design</em>ed to make us buy things. The science of supermarket <em class="keyword">design</em> is widely practised with the intent of guiding shoppers to purchase not only as much as possible, but the specific products the supermarket wants us to buy. From the positioning on shelves to the layout of the store, every effort is made to control the behaviour of the shopper.

This, almost by definition, flies in the face of what we might term supermaket usability or even consumer friendliness. The customer&#8217;s objective is to get into the store, collect the things they need, get to the check-out and leave as quickly as possible. 

Organic Peas

An example &#8211; the other day I needed to pick up some garden peas. We try to buy organic whenever possible, so I was initially pleased to see a section labelled &#8216;Organic Vegetables&#8217; in the store. The supermarket were trying to promote organic veg, and I had been led straight to it. The fact that there were&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=245">Designing URIs</a></h2>
            
            <p class="excerpt">&hellip;So this is a quick hack of a post I&#8217;ve been spending far too long failing to complete. Time to just get it out the door. If parts are nonsensical, please accept my apologies. You get what you pay for.

A fair bit has been written over the years about <em class="keyword">design</em>ing good URIs. Whilst traditional teaching on the subject must also apply to web applications to some extent, how far does it go? Does the nature of the documents being served (in this case &#8216;active&#8217; documents as part of a larger application) hold sway over the URI of the page?

First Principals

I tend to be pretty fussy about what appears in the location bar of any sites or apps that I architect. Partly this is down to aesthetics and some idealist goal of elegance, but primarily it rests with the core values of sustainability, perception of stability and also ease of use. Let&#8217;s unpack that.

The subject of sustainability in URI <em class="keyword">design</em> should be familiar to us all. At a base level, /contact is good, but&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=247">User Defined Functions Considered Harmful</a></h2>
            
            <p class="excerpt">&hellip;I admit I should have listened to Rachel. She told me that SQL Server user defined functions (UDFs) were evil, but in the face of zero evidence to back up her claim, I went ahead and <em class="keyword">design</em>ed the linchpin query in our latest project using beautifully <em class="keyword">design</em>ed logic blocks all extracted out to UDFs.

The query is exceptionally complex, having to take account of countless business rules and turn them into result set filters. In fact the query is the crux of the entire web app, with all roads leading to its door. In order to <em class="keyword">design</em> the query to be as elegant and maintainable as possible, I made heavy use of UDFs to compartmentalise each rule. The <em class="keyword">design</em> of the query was pretty good &#8211; with carefully chosen function names the whole thing read more like a screenplay. And in development it ran beautifully.

Now we&#8217;re in alpha testing, and the client has begun loading data. The primary table has about 40,000 rows, and there are perhaps a dozen joined tables containing anything up&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=249">Emerging from the Shower</a></h2>
            
            <p class="excerpt">&hellip;I share a similar discomfort with the term ajax as I do with DHTML. Back in the day we took the concept of HTML styled with CSS, made interactive with JavaScript and accessed through the Document Object Model, and termed it DHTML. This act alone made it easy to describe how those technologies could be used together for what was, at the time, innovative things.

The same is true of ajax. It stands of Asynchronous JavaScript and XML, which in turn stands for look at me I&#8217;m a geek and you don&#8217;t understand what I&#8217;m saying. It does, however, give us a useful way of describing the whole xmlhttprequest thing and how JavaScript, XML, server-side code and out-of-process HTTP requests can interact with HTML to make interfaces a little more interactive/responsive.

We don&#8217;t use the term DHTML any more because what was innovative when the term was invented is every day now, and no one needs a generic term to describe that stuff. We all know how HTML, CSS, JavaScript and&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=251">Everyone Has a Clock</a></h2>
            
            <p class="excerpt">&hellip;If you build web sites for a living, you will no doubt have come across a client who, despite lack of any logic or reason, wants either the time or date displayed on their site. Unlike a vast number of other common web <em class="keyword">design</em> sins, I have to say that this is not one I&#8217;ve ever fallen foul of (despite working on a number of sites that have already been cursed with the presence of the day and/or time before I inherited them).

Whilst there are a small number of cases where it makes sense to present the user with a timestamp (project management tools like Basecamp spring to mind), most of the time it&#8217;s an unnecessary waste of space. Most commonly used browsing platforms, including my S60 phone, have a clock built in. If I want to know the time or the date, it&#8217;s only a brief glance away. There&#8217;s no need to waste space on the page by reiterating the obvious.

Today I was at the Science Museum in London, and was interested to see their exhibition of computing through&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=265">Upgraded to Textpattern 4.0.1</a></h2>
            
            <p class="excerpt">&hellip;I&#8217;ve been running a fairly ancient build of Textpattern on this site since I relaunched with this <em class="keyword">design</em> back in August last year. Since then, TXP has undergone massive changes, and some important security fixes have been made. Although none of the potential security problems are known to have been exploited, I was getting pretty itchy about it and thought I&#8217;d better update.

The main reason I&#8217;d hadn&#8217;t upgraded sooner was that I&#8217;d hacked around with my install quite a bit to get the markup how I wanted it. There were some quirks with TXP a year ago, and some of the markup was still hard-coded into the files and not exposed to the templating system.

So I thought that upgrading to v4.0.1 would be a major nightmare, and had pretty much resigned myself to biting the bullet and getting on with somehow, anyhow getting my site upgraded.

I was pleasantly surprised to find that I had to do absolutely nothing. I checked out the latest stable build from svn,&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=279">Site Maps for Web Applications</a></h2>
            
            <p class="excerpt">&hellip;Site maps &#8211; and by that I mean the information architecture documents used in the web site <em class="keyword">design</em> and production process, not the catch-all navigational monstrosities found lurking in footers far and near like some trenchant swamp-thing biding time to attack &#8211; are pretty much the de facto method of visualising site structure in a way that can be documented. They&#8217;ve been around for years, Jesse James Garrett has come up with a formalised visual vocabulary for expressing them. Known, perhaps not loved, but certainly tried and tested.

Site maps generally fall into two different categories:- those that document the navigational structure of the site, and those that describe interaction flow. As the days of enormous, static sites vignette to make way for sites driven by logic not links, we naturally see a shift in emphasis from navigational maps to those which document interaction. The question worth exploring, however, is can this form of documentation continue to prove&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=295">The Biggest Unsolved Problems of Web Design</a></h2>
            
            <p class="excerpt">&hellip;As a result of travel arrangements, I wasn&#8217;t able to catch Eric Meyer&#8217;s opening keynote on the first morning of @media 2006 as I&#8217;d hoped. A podcast of the keynote is now available, so I took the opportunity to catch up on what I&#8217;d missed. You should too.

Eric&#8217;s presentation looks back over the last 10 years of the evolution of CSS &#8211; which is far more interesting than it may initially sound, I promise. I guess the recurring theme is that of community involvement and shared knowledge. The history of CSS and modern web development is peppered with instances of individuals making discoveries, having innovative ideas and engineering clever work-arounds to found problems and implementing and sharing that knowledge for the benefit of the industry as a whole. 

I guess the classic example of this is the story behind the invention of the Box Model Hack. Jeffrey Zeldman had problems with a particular bug, the end result of which was that it wasn&#8217;t&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=297">Joining Yahoo!</a></h2>
            
            <p class="excerpt">&hellip;This week I started working for Yahoo!, as seems to be the fashion these days. I&#8217;ve joined Chris Heilmann, Stuart Colville, Mike Davies, Norm Francis and a whole bunch of other talented and clueful web developers in Yahoo! Europe&#8217;s London office, tucked away nicely at the edge of Covent Garden. I have to say I&#8217;m pretty excited to be joining a company that seems to really get it when it comes to the web &#8211; from my perspective, the fact the Yahoo! is currently the biggest publisher of microformatted data says a lot.

Obviously, I&#8217;ve been hearing an awful lot of criticism, since talking to people about my move, that Yahoo! is apparently trying to hire most of the UK standards-aware development community. This is something I&#8217;ve had to think carefully about when considering my decision to join. Ultimately, I&#8217;ve failed to find a compelling argument as to why it&#8217;s bad for Yahoo! to be hiring lots of well-known developers. From the&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=304">24ways Returns For 2006</a></h2>
            
            <p class="excerpt">&hellip;Call me mad, but your favourite web geek advent calendar is back for a second season at 24ways.org. The idea is that we post a new web <em class="keyword">design</em>/development article every day from the 1st December all the way up to Christmas. Last year was tough work but well worth it as all the articles were very well received.

I can&#8217;t promise we&#8217;ll top the success of last year, but at the very least we&#8217;ll try to match it. I&#8217;ve got a great line-up of authors all ready to go, including some familiar names from last year as well as some fresh contributors. I&#8217;ll not spoil the surprise &#8211; you&#8217;re going to have to check back each day and see what we&#8217;ve got in store.

To kick the proceedings off today, I&#8217;ve opened with an article on building a widget like Safari RSS&#8217;s article length slider. This enables the user to dynamically adjust the length of text shown on the page. I&#8217;ve called it the Tasty Text Trimmer for want of a better name. Feel free&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=305">Changes Afoot at WaSP</a></h2>
            
            <p class="excerpt">&hellip;I don&#8217;t remember exactly when it was that Jeffrey Zeldman dropped me a line and asked if I&#8217;d join the Web Standards Project to help form their first task force. I guess it was some time in 2001 &#8211; I&#8217;d need to dig a lot of mail out of the archives to find exactly when. Together with Rachel Andrew we formed the Dreamweaver Task Force and began working more closely with Macromedia on improving their product&#8217;s support for web standards.

A couple of years later, wanting to get a bit more involved with core activity, I took on the vacant &#8216;press&#8217; role, wrote some ridiculous press releases, helped launch Browse Happy and eventually found out (almost by accident) that I&#8217;d been opted on to the Steering Committee. A year on and I took on the role of Strategy Lead.

This week, along with the wonderful Kimberly Blessing, I took over from Molly and became Group Lead of the Web Standards Project. Yikes. It&#8217;s been five years or so, but it feels&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=310">The State of Textpattern</a></h2>
            
            <p class="excerpt">&hellip;This site is published using Textpattern, and has been for more than four years. In fact, save for a few of Dean Allen&#8217;s own sites, this is pretty much the longest standing Textpattern installation going. I jest not. A major reason for starting this site at all was to play around with this new toy Dean had given me to try out. Back then I was running PHP as a CGI, which exposed a number of compatibility issues and helped iron out a few problems long before Textpattern was released to the public. 

It&#8217;s not been a perfectly smooth journey. From the get-go this was always something Dean was working on his is limited free time, and releases would come in fits and starts. Even once Textpattern was released to the public, updates would sometimes be months apart. All for good reason, and security fixes were never neglected, but you know, months.

Eventually, of course, the inevitable happened and Dean had to hold his hands up to really not having the time to work on Textpattern&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=316">Preparing for 24ways</a></h2>
            
            <p class="excerpt">&hellip;With December just around the corner, you can bet your bottom dollar (or even just your bottom) that I&#8217;m in the throes of preparing for yet another year of 24ways. Just as we&#8217;ve done since 2005, we&#8217;ll be serving up a new web <em class="keyword">design</em> or development article each day for the first 24 days of December. Consider it something like a geek advent calendar, except without the little doors.

This year, we&#8217;re aiming to try something a little different with the comments. Comments on articles can be great, but sometimes they can add more noise than value. This is especially true if an article gains traction and is linked to in places like Digg or Slashdot, bringing in fresh readers without any context. Whereas in many places it&#8217;s not uncommon to see hundreds of comments per post, we&#8217;d really like to encourage an environment of well-considered commentary that actually adds something to the conversation. 

So how do we go about encouraging that? I think the first&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=321">Armadillo v3</a></h2>
            
            <p class="excerpt">&hellip;As much as I attempt to avoid navel-gazing meta-posts, humour me briefly as I announce that for the first time in more than three-and-a-half years I&#8217;ve updated the <em class="keyword">design</em> of my site. If you&#8217;re reading via a feed (and if you&#8217;re not, c&#8217;mon!) come take a look. As I said back in August 2004 when I last re<em class="keyword">design</em>ed I&#8217;m very much a developer rather than a <em class="keyword">design</em>er and so it&#8217;s not going to win any awards, but I do like to try and keep the place looking nice. 

Points of note

One of my objectives apart form the visual refresh was to make good use of microformats from the ground up, so you&#8217;ll find the posts formatted with hAtom, as well as hCards and XFN all over the place. There&#8217;s more to do, but it&#8217;s a good start.

A lot of what I write is fairly text-based technical stuff, so I wanted to include more images to try and makes the page more visually interesting. I enjoy photography and use Flickr a lot, so I&#8217;ve simply used a standard&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=326">Content Management Nightmares</a></h2>
            
            <p class="excerpt">&hellip;I&#8217;ve come into contact with a lot of different content management systems over the years, from the off-the-shelf to the handmade by pixies varieties. Apart from the almost universal truth that everyone hates their content management system, I&#8217;ve found them all to be remarkably different. From the basic to the complex to the complex-but-should-have-been-basic they&#8217;re all out there and most of them are dangerous.

Whilst working in a <em class="keyword">design</em> agency seven or eight years ago where I was building mainly ASP/VBScript projects, we were approached by a client to perform a re<em class="keyword">design</em> of their existing site. The site had originally been built by one of the very large <em class="keyword">design</em> agencies who, as was quite common at the time, had offices all over the world. Part of the re<em class="keyword">design</em> necessitated some changes to their custom-built ASP content management system, so we set about requesting the source code from the original <em class="keyword">design</em> agency.

Whilst our client was based at an office in London,&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=327">Content Management Without the Killing</a></h2>
            
            <p class="excerpt">&hellip; Last week I had the pleasure of presenting once again at the London @media conference, this time on the subject of Content Management. It was the first time I&#8217;d run that particular presentation, and consequently I&#8217;d like to have spent less time on the introductory material and more on the latter half, but on the whole it was pretty well received. 

I&#8217;ve put the slides up on SlideShare, but they don&#8217;t tell much of the story on their own. Therefore, I&#8217;m planning to serialise some of the main parts of the presentation as a series of articles, over at edgeofmyseat.com.

The first of those is 8 Features to Look For When Choosing a CMS, and unsurprisingly runs through a number of things to take into consideration when you&#8217;re making your next content management system <em class="keyword">design</em> or purchasing decision. Clearly, every project&#8217;s needs are totally different, so I&#8217;ve tried to focus on the main underlying features and attributes that should stand you&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=329">The Clangers' Guide to Microformats</a></h2>
            
            <p class="excerpt">&hellip;I had the pleasure of being able to attend Oxford Geek Night 7 last month to present a five minute microslot called The Clangers&#8217; Guide to Microformats. There&#8217;s not much you can cover in just five minutes, but my aim was to give a brief overview of the concept of microformats to those who may not yet be familiar with them.

The Clangers was a BBC television children&#8217;s programme made in the late 1960s and early &#8217;70s which remained in heavy rotation right through to when I was growing up in the 1980s. These little pink crocheted space creatures would communicate in a rhythmic series of whistles, which would give us humans enough of the gist to be able to follow along, but didn&#8217;t really communicate any detail. My attempt was to liken this to how we communicate our content in HTML, which has enough semantics to give us rhythm and intonation, but none of the detail. Microformats, of course, provide that detail.



The Clangers Guide to Microformats from drewm&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=331">What Brian Cant Never Taught You About Metadata</a></h2>
            
            <p class="excerpt">&hellip;Last month I had the pleasure of speaking at the Geek in The Park event up in Leamington Spa, here in the UK. Whilst the weather didn&#8217;t quite hold out in the way we&#8217;d hoped, the whole day was still good fun. The evening events took place under cover in a pleasant local half pub, half nightclub sort of place. On the bill was Jon talking about icon <em class="keyword">design</em>, and me talking about Brian Cant.



Growing up in the 1980s, Brian Cant was a familiar figure in my childhood. He was the friendly face presenting Play School on the television, reading a story on the BBC&#8217;s Jackanory or narrating the classic stop-frame animated Camberwick Green, Trumpton and Chigley series. On the drive up to Leamington Spa, and admittedly rather too late, it occurred to me that having been working on the web for more than ten years, it&#8217;s reasonably likely that a good proportion of the audience would be younger than me and therefore miss the cultural reference. Ah well. Kids these days.

As it&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=338">Supersleight jQuery Plugin for Transparent PNGs in IE6</a></h2>
            
            <p class="excerpt">&hellip;I never meant to become obsessive about getting PNG transparency working nicely in IE6. In the summer of 2003, I hit across a situation on a client project where what the <em class="keyword">design</em>er wanted required the use of PNG transparency. The script that came to hand to get this working in IE6 at the time was called Sleight, but that only dealt with applying the filter to IMG elements. My <em class="keyword">design</em> needed to do the same for CSS background images, so I hacked up a different version of the script for that purpose, called it bgSleight, and occasionally updated it.

Back in late 2007, I gathered up the work I&#8217;d been doing on bgSleight along with updates from Aaron Boodman&#8217;s original Sleight script and wrote Transparent PNGs in Internet Explorer 6 over at 24ways. In the article I go into some depth about the issues and the pitfalls of using an IE filter, so it&#8217;s a useful background read. Included with the article was a script I called SuperSleight which attempted to wrap up both my work&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=339">Easing The Path From Design to Development</a></h2>
            
            <p class="excerpt">&hellip;Earlier this month, I ran a half day workshop at Future of Web <em class="keyword">Design</em> London on the subject of easing the path from <em class="keyword">design</em> to development. The premise was that lots of people experience difficulty and even conflict at this point in projects, which can cause substantial derailments.

As a company who work providing development services to primarily <em class="keyword">design</em> agencies and startups, this is an area we deal with day to day, and I think one that we&#8217;re pretty good at making as smooth as possible. So I was pleased to put something together on this subject when the guys at Carsonified asked if I could run a workshop.

At 3.5 hours, there&#8217;s a lot of material which doesn&#8217;t make much sense as a deck of slides without the commentary. I had over 600 slides. Instead of putting all those up on slideshare, I figured it would be more useful to publish the outline I created the slides from. Outline: Easing the Path from <em class="keyword">Design</em> to Development 

Thanks to the guys at Carsonified for asking&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=343">The Fallacy of Page Zooming</a></h2>
            
            <p class="excerpt">&hellip;A couple of weeks ago, Cameron Moll posted an article entitled Coding like it&#8217;s 1999 in which he put forward his case for switching back to using HTML4 and sizing his text in pixels. I&#8217;m not going to cover the HTML issue today (although I happen to disagree with Cameron&#8217;s choice), but I did want to put some thoughts down on the issue of sizing text in pixels.

The argument that many <em class="keyword">design</em>ers put forward is that working in relative sizes (such as percentages or ems) is hard work because you have to take inheritance into account. In fact, Cameron refers to it as the &#8220;burden of calculating relative units throughout a CSS document&#8221; in contrast to &#8220;the convenience of absolute units&#8221;. I can absolutely see his point on a surface level.

However, I see no reason to use pixel-sized text, and in fact I think it&#8217;s shooting yourself in the foot to do so.

The approach I take is to size the body element in ems, and then use percentages from that&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=344">Own Every Aspect of The Design</a></h2>
            
            <p class="excerpt">&hellip;Most of the projects I work on are for <em class="keyword">design</em> agencies &#8211; they <em class="keyword">design</em> how the site or web app should look, and then bring it to us to attach the electrodes, crank up the power and bring their creation to life. 

One thing that every project has in common is that there&#8217;s always a bit more to be <em class="keyword">design</em>ed than is apparent at the surface level. Even a simple five-page brochure site has more to think about than the layout and content of the five main pages. There&#8217;s things like the site map, accessibility statements and legal pages. If your site has forms &#8212; even a simple contact form &#8212; you need to think about the messaging around it. What does the user see when the form has been completed? What&#8217;s in the email that is generated?

The reality is that in most cases there are lots of details that don&#8217;t get planned in right from the start and end up being implemented by a developer. Perhaps by me. No matter how conscientious the developer, they&#8217;re&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=347">Moving from Basecamp to ActiveCollab</a></h2>
            
            <p class="excerpt">&hellip;At edgeofmyseat.com we do most of our work without meeting, and for a lot of the time without out physically talking to our clients. Certainly once a project&#8217;s underway, day to day interaction occurs online. With multiple projects in some stage of active development at any one time, and lots of messages being fired off between multiple team members, if we tried to do this by email it would quickly become unmanageable. 

Enter Basecamp

As a solution to this we use Basecamp as a project management and collaboration tool between us and the client. There are pretty much just two things it does well for us: keeping conversations organised and archived, and maintaining a centralised collection of project files (such as <em class="keyword">design</em> files, specs, and so on).

Just recently we hit up against our account limit for active projects and so have been faced with the option to close down some projects (which isn&#8217;t really an option) or upgrade the account. We use Basecamp pretty much all day&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=349">The Curse of max_file_uploads</a></h2>
            
            <p class="excerpt">&hellip;Today marks a year since we shipped the first version of Perch, and we celebrated by putting out another big release. We&#8217;ve been following a strategy of shipping medium-sized updates regularly throughout the year (July, October, December, February), each time fixing any issues that users have reported and always adding some new functionality to make it worth the trouble of updating.

This latest release has been a big one. We&#8217;ve reflected that in the version number, jumping from 1.2.6 to 1.5. As well as the usual fixes and features, we&#8217;ve added an entire developer API enabling the extension of Perch through apps. The first app we&#8217;ve launched with is for the creation of new pages.

One bug that cropped up late in the development cycle had to do with a change to PHP that caught us by surprise. PHP 5.2.12 had added a new INI directive called max_file_uploads, <em class="keyword">design</em>ed to prevent DOS attacks. The supposed attack would work by uploading a huge number of files to a&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=350">Launch Week</a></h2>
            
            <p class="excerpt">&hellip;I&#8217;m in the fortunate position these days of being able to see lots of my work go live all the time. We work on lots of projects for a whole range of clients, and we&#8217;re shipping stuff constantly. That&#8217;s great, but what&#8217;s even better is when it&#8217;s your own projects that you&#8217;re shipping.

This week (and it&#8217;s only Tuesday) has been a mammoth week for launching some of the stuff we&#8217;ve been working on lately. First up, yesterday we shipped a new version of our little CMS product Perch. Version 1.6 includes lots of big new features, many of which are centred on improving user confidence when making edits to their sites. Lots of the end users who wind up using Perch are small business owners, administrators, club secretaries, all the sort of people who easily might not be that confident using online software. So we focussed on making them more comfortable. We added multi-level undo, save-as-draft and content preview. We also did some interesting&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=354">Ideas of March</a></h2>
            
            <p class="excerpt">&hellip;When I started this site in 2003 &#8212; as best as I can tell it was 2003 &#8212; a individual&#8217;s personal site or blog was pretty much their primary method for joining the online conversation. If you had something you wanted to share, you wrote a blog post. Others would read it, and if they found it to be of value they might link to it in a post of their own. Or leave a comment. That&#8217;s how we all communicated. 

At that time there was an amazing wealth of content being posted to blogs, and truthfully, it was the primary way I picked up information around the subject of web <em class="keyword">design</em>, and spurred me to form my own opinions on subjects I wouldn&#8217;t have otherwise thought about. Because you can&#8217;t blog without an opinion.

One thing I&#8217;ve found over the last four-and-a-half years of using Twitter (where did that time go?) is that the opinions and ideas that I used to consider for a while and then focus into a blog post now get fired off into a 140 character tweet&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=357">The Lure of On-page Editing</a></h2>
            
            <p class="excerpt">&hellip;I get asked quite often why Perch doesn&#8217;t offer any sort of on-page editing. It&#8217;s something we&#8217;ve given a lot of consideration to, and as it&#8217;s an interesting software <em class="keyword">design</em> issue I thought I would document some of my reasoning here.

So what do I mean by on-page editing? In the context of a content management system, we&#8217;re talking about the ability to make edits to a page directly by clicking on the content (or a nearby Edit link) and manipulating it in place on the front end of a website. The alternative approach in contrast to this &#8212; and the approach we currently take with Perch &#8212; is for the user to go to a dedicated control panel to edit the content away from the page.

There are a couple of issues with on-page editing in my mind.

The technical

The big technical hurdle with on-page editing is the necessity for the CMS to inject its UI into the front-end page. At first that doesn&#8217;t sound too bad, but the more you think about it, the&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=358">The Best Forms Implementation I've Ever Built</a></h2>
            
            <p class="excerpt">&hellip;The one thing that will really kick your developers&#8217; butts when building an interaction-heavy web app or site is the forms. Forms can be a lot of work to implement. Get the technical <em class="keyword">design</em> of your form generation/handling/validation system right and your project can fly along. Get it wrong, and you&#8217;re sunk in work that becomes tedious and demotivates everyone involved.

Now, before you tell me that this is a non-issue because no one builds individual forms anymore and that they&#8217;re all auto-generated by frameworks, I&#8217;m talking about the bit that goes on inside the framework. My consideration is how you <em class="keyword">design</em> a system that outputs forms without resulting in a sucky literal representation of a database row in HTML. 

Anyone who cares about interaction <em class="keyword">design</em> and gathering accurate data carefully <em class="keyword">design</em>s and tunes forms individually to suit the task in hand. Auto-generated data entry forms are fine for routine back-office jam-this-data-in-a-database-table tasks,&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=361">How To Make Your Website Fast</a></h2>
            
            <p class="excerpt">&hellip;Since launching the new Greenbelt website this week, one thing a lot of people have commented on and asked about is the speed. It&#8217;s noticeably fast. I&#8217;ve never heard someone complain that they really like a site, but goshdarnit if it weren&#8217;t so fast. Fast beats slow, every time. So we wanted to make it fast from the outset.

That said, boring doesn&#8217;t beat fast, and neither does not reflecting the brand. Greenbelt Festival is a buzzing, vibrant event. It also has a strong identity developed by our <em class="keyword">design</em>er on this project, Wilf Whitty at Ratiotype. A craigslist-style non-<em class="keyword">design</em> wasn&#8217;t going to cut it, no matter how fast that may be. As a result, the site is full of big photos and iconography, even video and audio. And it&#8217;s still fast. 

I don&#8217;t even remotely claim to be any sort of authority on the subject, but I can tell you what worked for us.

Start with good hosting

It frequently surprises me how little some <em class="keyword">design</em>ers and developers appear&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=362">Why Use a Database With a Small CMS?</a></h2>
            
            <p class="excerpt">&hellip;As the lead developer of the small CMS Perch, I&#8217;m often asked why we use a database at all, when Perch is aimed at smaller websites. There seems to be an assumption that using a relational database like MySQL is both complex, and somehow &#8216;heavier&#8217; than needed for a &#8216;lightweight&#8217; solution. 

I wanted to talk a bit about both these issues, as the misunderstanding is pervasive and can lead to poor choices if you&#8217;re not careful.

Databases are hard to use

When learning HTML, every budding web <em class="keyword">design</em>er soon wants to start working with images. The problem is, images on the web are complex. You have to learn about the different formats (JPEG, GIF, PNG, SVG&#8230;) and when to use each. You need to learn about scaling images to the appropriate size, and exporting from your graphics tool in a way that optimises for file size. You even need to understand some basic conventions about file naming and, when it comes to adding the  tag to your page, file paths.&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=363">24 ways and Perch 2.1</a></h2>
            
            <p class="excerpt">&hellip;When I launched 24 ways in 2005, it was pretty much a last-minute project. To get the site live quickly, I just reached for the blogging system Textpattern, as I was familiar with it. Textpattern did a good job managing articles, comments, RSS feeds and so on, but for one reason or another development stagnated. 

Textpattern&#8217;s flexibility enabled me to implement some custom features as plugins (like the day-by-day navigation down the side of the article pages) but basic features like comment spam detection were causing problems. Replacing a CMS isn&#8217;t usually a fun job, so I carried on with Textpattern for longer than perhaps I should have.

Fast forward to 2012, and we now have our own CMS, Perch. I&#8217;m currently working Perch 2.1, and so it made sense to rebuild 24 ways using it and at the same time test the new features I&#8217;ve been working on.

Rebuilding the site with Perch took about a day, and migrating the content took another day on top of that.

Improving&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=366">Rebuilding 24 ways</a></h2>
            
            <p class="excerpt">&hellip;As those with long memories may recall, I first launched 24 ways in December 2005 as a fairly last-minute idea for sharing a quick tip or idea every day in advent. I emailed some friends to ask for contributions, and was overwhelmed by the response. Instead of the tips I&#8217;d had in mind, what I got back was full-blown articles prepared with depth and care.

I <em class="keyword">design</em>ed (and I use the word lightly) the site myself, got it up and running using blog software, and off we went on a twenty-four day roller coaster. 

The site was such a success that we repeated the process in 2006. When recruiting authors for our third year in 2007, Tim Van Damme asked me to do something about the terrible <em class="keyword">design</em>. I pretty much said &#8220;well, go on then!&#8221; and that year we launched with an all-new look. Tim did an amazing job with a <em class="keyword">design</em> that was well ahead of its time, both visually and technically. It&#8217;s hard to remember now, but the heavy use of RGBA colour meant that the <em class="keyword">design</em> only&hellip;</p>
        	<p class="source"></p>
        </li>

        <li class="odd">
            <h2><a href="/perch/addons/apps/perch_blog/edit/?id=367">Why is Progressive Enhancement so unpopular?</a></h2>
            
            <p class="excerpt">&hellip;A little earlier today, having read how Sky broadband had blocked the jQuery CDN I tweeted 

 Sky broadband erroneously blocks http://t.co/5i7EXxYlDy and that’s why we don’t depend on JavaScript, kids.— Drew McLellan (@drewm) January 27, 2014

To which many responded this is why we don&#8217;t rely on CDNs and how you can (shock, horror) even host your own JavaScript fallback and how you make a hole at each end of the shell and suck with a straw. In order to clarify the problem, I followed up with 

 What the Sky/jQuery thing teaches us is that unpredictable factors can cause good JS to fail. Plan by <em class="keyword">design</em>ing pages to work without first.— Drew McLellan (@drewm) January 27, 2014

The internet, as a network, is <em class="keyword">design</em>ed to be tolerant of faults. If parts of the network fail, the damage gets routed around and things keep working. HTML is <em class="keyword">design</em>ed to be tolerant of faults. If a document has unrecognised tags, or only partially downloads or is structured weirdly, the browser will do its&hellip;</p>
        	<p class="source"></p>
        </li>

    </ul>
/* No context defined for this component. */
  • Content:
    .search-results {
    	list-style: none;
    	margin: 0 $main-gutter $main-gutter $main-gutter;
    	padding: 0;
    }
    
    .search-results h2 {
    	@include font-scale(base, helvetica);
    	font-weight: 400;
    	margin: 0 0 $half-gutter 0;
    }
    
    .search-results h2 a {
    	color: palette(type, dark);
    }
    
    .search-results .excerpt {
    	@include font-scale(m, helvetica);
    }
  • URL: /components/raw/search-result/search-result.scss
  • Filesystem Path: src/components/17-search/01-atoms/01-search-result/search-result.scss
  • Size: 334 Bytes
  • Handle: @search-result
  • Preview:
  • Filesystem Path: src/components/17-search/01-atoms/01-search-result/search-result.hbs

There are no notes for this item.