A Movable Type to Wordpress migration, a complete site redesign and the addition of a host of new features are just part of the all new Content Developer. Please pardon the dust as the last few nips and tucks are finished out.
I learned some tips and tricks and found some resources that can help this type of migration go a little smoother. Stay tuned for more details.
The beginning of a new month feels like an appropriate time to spend a moment talking about the new look here at ContentDeveloper.com.
Over the last few weeks Content Developer has moved from the 700 pixel wide two column look it started out with 18 months ago, to a brief stop last week on a 800 pixel wide 3 column design, to the now 940 pixel wide 4 column design where I think we will stay for a while.
The main reason for the brief stop at the 3 column design was my own personal difficulty in kicking the 800X600 screen resolution user to the curb. Well, kicking to the curb may be a little hyperbolic since the 800X600 user can still access Content Developer just fine, but now they have to scroll a bit left to right to see everything.
Many developers and designers are also apparently still struggling with this 800X600 question.
Choosing the highest value adding minimum user spec to serve as your design baseline has always been an important first step for many online projects. Developers thankfully were able to toss the 640X480 user overboard many moons ago and for the longest time all the projects I’d been associated with usually settled in at 800X600 as the generally accepted bottom rung of the user ladder. That’s a comfortable position to defend and continues to make some sense seeing as how even Windows XP Professional x64 still defaults to Super VGA on a fresh install.
So 800X600 is still in the game, but after reviewing some recent data and implementing 4 column designs that seem to flourish with that little bit of extra space on some other sites, I’m finally starting to lean toward adopting the 1024X768 user as the new default minimum spec.
Every project has its own decision process to go through, but should 1024X768 be the new default minimum design spec for browser based projects? And if you do make that leap are you committing that all too common error of putting the interests of designers and developers over the interests of the user?
According to W3Counter.com 800X600 resolution users now account for about 10-11% of internet users.
This is just one source and though their sample size is large it probably isn’t a truly scientific representative sample. Other sources (1, 2) show that it might be a bit low but do suggest that the figure is at least in the ballpark.
That 10%-20% range of 800X600 users is still plenty big enough for a site delivering mainstream content to a wide audience to care about and pay attention to. If I’m building a general audience site designed to deliver information about health care, then I am building with that 800X600 user still very much in mind. But what pushed me over the edge for this site was an acceptance (rationalization?) that the typical reader of blogs about creating content and media distribution is probably not running on that 800X600 minimum spec.
There is an argument to be made that the use of percentages in your CSS design is the answer to this challenge. You can create attractive, clean and functional designs built around allocating your screen real estate with ratios, but sometimes the use of percantages create new viewing inconsistency issues and impose their own limitations on what you can ultimately do.
So despite some still lingering cognitive dissonance I decided to stick with a fixed width design but say goodbye to 800X600. You’ve been a reliable friend 800X600 and we will likely meet again on other projects, but your time may have finally passed for this site.
A couple other additions to the new version of Content Developer I also wanted to mention are the freshened up masthead and the introduction of headlines from other blogs and traditional news sites about content.
These headlines are delivered via that great rss feed splicing and redistribution combo of feedblendr and feed2js. Feed2js now has moved off of its longtime home on the maricopa.edu servers and onto their own site provided by Modevia Web Services at feed2js.org. The announcement on the movement of feed2js also notes that an open source feed2js site will be coming to sourceforge soon.
A couple other indicators worth noting from the W3Counter stats is the still rising market share power of Firefox…
…and the steady 3% market share of Mac users.
Has that Mac market share number changed at all in the last 10 years? Even after all those great commercials?
I hope you find that the new look here works well for you.
For those drilling for more information about this site, here is a brief resume of the author and a permalink that talks about the inspiration and mission of ContentDeveloper.com.
After seeing so many 404 error messages in the access_log about favicon.ico, finally took the time to create a favicon. Pretty straighforward with Photoshop and the icon plugin for photoshop from telegraphics.
Learned that favicon.ico won’t show up in IE6 unless user adds site to their favorites. Also appears to be hit or miss getting it to show up in Bloglines my feeds section. Works like a charm in Firefox though.
Some tutorials and info from Microsoft, Go Live and Photoshopsupport.com
Not really sure who to root for in the Yahoo vs. Google manhood measurement contest about whose index is bigger.
But I have noticed that Yahoo’s Slurp Spider was much more active in our site traffic logs, UNTIL, we added Google’s Adsense recently. Now the GoogleBot is leaving crumbs all over our access_log.
Not to push the manhood measurement metaphor too far, but this may be another example of once you reach a certain “critical mass” it may more about what you do with you have.
More for the sake of learning how to do it as opposed to dreams of accumulating wealth, added Google’s Adsense to the blog this week.
While researching how to set up this site, I read many MovebleType users suggestions about using the mysql option for handling the database functions of the blog.
I chose to start out using the Berkeley db option for two main reasons.
When thinking about how to put this site together, it feels out of sync to break it up by equipment (cameras, mics, software etc…)or skills (flash development, animation, editing etc…). Doesn’t seem to match the vibe the site is after.
2005 marks a big move for my company.
We are moving away from a primary focus on delivering content development services to corporate clients and are taking the leap into developing our own original content.
The corporate work is good work and we will continue to do some of it, but we have a passion for this new area and feel a responsibility to explore where that passion will take us.
Have been using a crude blog as a way to keep our corporate site up to date with basic headlines since the end of 2002.
Works for that site as it involves just putting a line or two of headlines up every month or so. With that load one can get away with just opening up the html page and putting in the new line.
That kind of approach certainly won’t work for a site where the blog is the core of the entire site, thus creating the need to find a platform to build this new site on.
So, why did we choose Movable Type as our software platform for this site?
