Archive for the ‘webdesigner’ Category

Building Web 2.0: A Case Study for Simply Fired’s Redesign

So today the Media Crumb team, with the help of Simply Hired’s Ops team, launched Simply into the wide open space of the web. It was a two month long process for MC and something we really enjoyed working on. It is not often that a design & development firm can say they have worked for truly helpful and forward thinking clients such as Simply Hired so we thought it would a perfect case study for the new MC site and blog. So if you ever wanted to know what is takes a small company like ours to build a “web 2.0″ (what ever that means) type site, check out or little case study of Simply Fired.


Before we get into the process first lets talk about what Simply Fired was like before the redesign. As you can see from the previous look and feel, the design was in need of some serious help out of the 90’s and back into the world of today. The great thing about a design like this is that a firm like ours can basically start from scratch without having to worry to much about carrying design elements over. So all intents and purposes, it’s really more of a new design than a re-design.

Before we got our hands on the site, Simply Fired was basically a blog of fun, interesting, or silly stories about being fired from around the net. The site also acted as a place for Simply Hired forum members to submit their own fired stories to be entered into monthly contests on the Fired site. The main problem with this idea was that forum members, on a completely separate URL, would have to resubmit the same forum story from the Hired forums to the Fired site. Not only that, but the submission was a simple email contact forum and not very engaging to the user. Sound confusing? That’s because it was.

So the idea behind the redesign was to completely stream line all the elements of the forum, the blog, and the stories into one easy to use site. The biggest issue with this was ensuring the old information, such as the blogs and forums, would remain untouched as well as keeping the forum on the other domain of Simply Hired. Users would need one login for two different domains and both of those domains needed to share stories seamlessly across URLs as forum posts and story submissions. Obviously this took quite a bit of tricky cross server scripting and session handling as well as getting different pieces of software (like Vbulletin, Movable Type and Pligg) to talk to one another. Not the easiest task, but doable.


Then again before we could even think about the development side, we had to figure out how the site would be laid out. As I said before, we were able to start from scratch and really take our own direction with the project which was great for the MC team. The biggest problem most clients have with designers is trust. When someone hires you to design something, they need to do so with total trust in your abilities as a designer. Without it, the client puts to much pressure or input into the design which can lead to something the end users of your website hate.

In order to combat this issue, MC sent out our “homework packet” to try and decipher what Simply Hired envisioned for the Fired site. The packet basically goes through the gamete of likes and dislikes, examples of other sites, typography, layout, color schemes, themes and more. For us, it is the best way to gather optimal input from the client without having to much guess work during mock up time. From there we build out our basic layout and refine the wire frame till we both agree it’s perfect.

This frame is then used as the base point for both mock ups and internal pages for the rest of the site. Using this in conjunction with our “homework packet” we started to build out the first set of mock-ups for the Simply Fired homepage. We usually only build out the homepage in a mock-up if there are no huge differences planed for internal pages. Some firms like to give out extensive wire frames and mocks, but in all honesty we find it slows down productions time immensely and only offers more room for sign offs and changes.

With Simply Fired, the team wanted to move towards an office theme. At first we thought of a simple desk space with office equipment in it, but soon realized that a site about being fired should tackle more of a distracted and depressed look. Most of these ideas came from the constant preliminary talks with the SH team and ours. With it, we came up with the final design examples you see below. You can see our progression through our first idea until we finally settled on the design you see today using their very own logo.

MC was lucky enough to have hit the nail on the head in terms of design and layout thanks to both teams constant input and details for the sites direction. The rest of the process was simply to build out the XHTML and CSS so that both teams could review things like color, font sizing, and basic changes to layout for blogs, stories, and other internal pages. In the end we love how the design plays on the fired theme and compared to the early mock ups, the final does well with both font and color scheme. Lucky for us, Simply Fired liked it too.


Before we began initial development we had two paths we could take:

  • Our own “digg clone” implementation using a foundation content management system (CMS) like Drupal.
  • Rely on an open-sourced design that already existed with this focus like Pligg.

There were some Drupal modules that would provide the voting mechanisms but to build a site that properly mimiced that of Digg would require additional pre-existing and custom modules to fit the look and feel of a true “digg clone.”

The other option, Pligg, was a content management system with a single focus: story submissions and voting. The choice seemed obvious.

With Pligg as our choice we had to then find out what it provided and what we would have to implement ourselves. Most of the functionality requested by the Simply Fired team’s proposal was already in the package with the exception of a voting system and a few custom modules for administrating contests and tagging additional text introductions onto category pages.

The biggest obstacle requiring the most intrusive software additions into Pligg would be binding it into the Vbulletin account information. The one theme that everyone agreed on was a solid user experience.

To allow users whom belong to their VBulletin forums to login and post stories on their new Pligg CMS they’d have to share account information at some level. That meant re-implementing all account authentication from a single source which we chose VBulletins accounting records because the forums were already established by Simply Fired and we wanted to utilize what already existed, not re-invent the wheel.

Unlike most Pligg implementations ours is unique in the fact that it really uses all authentication and user management from a VBulletin database while maintaining a secondary set of account information for Pligg’s story submissions. The few fields that were in common are kept in sync at all times. Once this was implemented the most important functionality was finished.

Unfortunately, we soon found out how beta Pliggs code truly was and ended up having to almost completely rebuild the way pligg handled voting, searching, tag handling, URLs, live viewing, tag clouds, multimedia and stories. Some of these issues revolved around Pliggs inability to support usernames with spaces, something VBulletin allows. Our implementation authenticates using the VBulletin system so many functions that display the username had to be tweaked in order to allow for spaces.

It is of no fault of Pliggs and we would still recommend the software to anyone that simply wants to clone diggs features. In fact the crew over at are constantly adding new feature sets and fixing bugs so I’m sure it is only a matter of time before they release a truly stable and semantic version. For us, we simply found that we spent way too much time fixing things and creating mods of our own then actually spending the time on completing the project.

The Simply Fired team wanted a voting module that worked much like that of the word-press voting module, so we molded our own around that concept. We also had to handle image and video submissions so users could share their stories visually. We created a bridge between Vbulletin and Pligg beyond that of authentication, allowing people to submit a story once in Pligg which would then automatically post the same story inside the Vbulletin forum in real time. The same was done if users posted inside the forum as well so that stories would automatically be submitted to the Pligg interface using the same users ID and username.

The VBulletin sync occurred via cron job because our goal was to leave the original VBulletin code untouched. This was done for two reasons: VBulletin is all but impossible to read and follow along with the fact that the site ran stable with VBulletin alone, changing its behavior added new dynamics and additional bugs that would slow down production.

To update the Pligg site “in real time” for the latest Movable Type (MT) blog, we created an MT template containing the latest blog data and fetched it from the MT site using PHP to open a web session and fetch the data on demand. This allows Simply Fired to cross-promote the Fired Blog and using the Pligg environment so that members could keep up-to-date with their blog while checking out new stories to vote on.

Beyond that we built additional of ways to display your own dynamic content based on tags and/or categories so the Simply Fired team could have total control over the data that was displayed for each area of the site. Utilizing Pligg to build our own Administrative modules took us a matter of hours to stabilize and demonstrate to the Simply Fired team. Our first module, the Pligg voting module, was built using some of the current modules as a foundation, additional ideas based on a popular word-press voting system and a little creativity.

We also created a module for adding text-descriptions to running contests based on their tag names, a full contest module for creating, managing and allowing users to submit their stories as contests. To top it off, we created a category text module to allow the administration to build additional dialog, promotions and introduction text when a user is searching for stories using the category links.

As stated, our biggest struggle was with Pligg and its instability. Running a few releases of the Pligg beta proved to be a large amount of work when it came time to update to a later revision. All of our code had to be migrated (in some cases line-by-line) because of the dramatic changes. In the end, old bugs were fixed but new bugs arrived that we had to handle. Searching for tags simply did not work, search itself was buggy at best, every social bookmarking option was malformed and broken and we still haven’t figured out how to get friendly URL’s to work “out of the box.”

Luckily the Pligg developers keep fairly clean code with understandable logic, something we cannot say when talking about VBulletin. They have not over-engineered and abstracted the project to the point of obscure code practices which means when Media Crumb finds a bug, we can fix it without any prior history in the code. They’ve not yet moved to a full and easy to use module system but adding our own custom modules proved to be simple and straight forward. The only downfall, they’re pretty hard-coded into the project (unlike the way Drupal’s CMS is designed).

To see more on Drupal vs. Pligg please checkout Derricks post on this topic.

In the end, it probably would have been easier to create something from scratch, but we also love all the work that is being done over at Pligg. Instead we built a true web “mashup” and created something that really interacts with the user on many levels. Now that the beta is finally launched, I can only hope we can continue to work on flushing out any unsightly bugs that we might run into and build an even better version of Simply Fired. Until then, I’m just happy to finally have some time to sleep. Thanks to the Simply Hired team and everyone that worked on the project. You guys really are a fantastic company and I hope all our readers enjoyed this little trip into our design and development world.

Categories: News, Web 2.0, webdesigner

Feature – Design Your Own Desktop with KDE 4

One of the best things about KDE 4, the newest release of the mainstream Linux desktop manager, is something it doesn’t do—force you to adapt to its way of running a computer desktop. Sure, the desktop environment boasts new 3-D effects, a polished theme, and improved functionality. But what KDE 4 does best is give users the ability to almost completely re-design their desktops, putting their programs, icons, and useful widgets wherever they see fit, on as many desktops as they want, to create their ideal workspace. I spent some time exploring the features of the less-than-week-old system, the results of which are after the jump.

If you wanted to see how KDE 4 looks right now without committing yourself to a new install, you can burn a live CD from the Kubuntu or openSUSE distributions, both of which plan to implement KDE 4 in their next releases. If, after these screenshots, you’re itching to switch for real, I’d recommend upgrading from inside a working KDE system rather than starting fresh, as none of the live CDs are officially supported yet. And there’s a good reason why—this is just the first release of a system that’s in many ways completely re-written, and a few important pieces are still missing from the whole. The developers have stated that KDE 4 is an intentional shift away from the norm, so those who rely on certain key programs to work might want to hold off until at least 4.1

But if you do boot up, the first thing you’ll notice about the new KDE is its clean-looking, ready-to-work interface. It has many of the same components as current KDE setups, but the icons and elements of the new “Oxygen” theme make it seem less like the Cute Lil’ OS That Could and more like a place to get things done (in my opinion, anyways).
Before jumping into the new-new stuff, note that the Start-like “K” menu (now named “Kickoff”) has undergone a major overhaul, adding an in-line search function and dividing your programs up into five categories, including a Google-like starred “Favorites” list. The only letdown is the big icon size and having to click to move through sub-menus, although fans of the older mouse-over menu can restore it by adding it as a widget.
About those widgets—they’re the heart of KDE’s desktop engine, named Plasma, and they’re a lot more powerful than clocks and mini-feed-readers, although they’re there if you want them. Everything you could put on the taskbar, and anything open source programmers can dream up, can be embedded anywhere on the desktop. After tinkering around a bit, I came up with my own taskbar-less desktop that was a bit crowded, but gave me a lot of functionality from the get-go:
expose_widgets.jpgThe widgets get covered up once you start opening program windows, but you can bring them to the fore and shade over your windows, Mac-style, with a Ctrl+F12 keystroke. They’re scalable vector graphics as well, meaning you can adjust them to any size, or even angle, and they’ll still look right. One notable widget is the “File Watcher,” which can display text from any file you point it at, making it a great way to track your text-based to-dos.

Mess around a bit, and you can come up with a lot of way to reorder your space in convenient ways. Put custom program launchers together across the screen bottom to create a Dock-like launcher. Move your window switcher to the top or the sides, or eliminate it altogether and stick with Alt+Tab. You can do many of these things in GNOME and in other operating systems, but KDE gives you a fairly blank slate from which to draw your own map to productivity.

KDE 4’s other big change is splitting the tasks of web browsing and file exploring between Konqueor and Dolphin, respectively. Dolphin, the newest kid on the block, brings split-view browsing for easier file transfer, and integrates the multi-format Okular viewing tool (seen in the background below) to view, bookmark and even add notes to files, making it easier to organize and sort them later.
Of course, no new Linux environment is complete without super-powerful, endlessly tweak-able Compiz-ish desktop effects, and KDE 4’s got ’em in spades. If you want your windows or menus to move a certain way, chances are you can do it.
There are many more improvements and changes in KDE 4, including improved multimedia handling, easier handling of plug-in devices and re-engineered core programs. What features did I miss that are worth noting? What do you hope to see come up next for KDE, GNOME, or any Linux system? Share your thoughts in the comments.

Categories: News, Open Source, webdesigner Tags:

Adobe’s Development of Thermo – Web App Development for Designers?

Thermo Logo

So I have been at Adobe MAX 2007 in Chicago all week. The whole experience has been really great. What was even better than that was a sneak peek at a new application that Adobe says that it will be releasing sometime in 2008 – code name “Thermo”.

I can not tell you how excited I was about this app. What is Thermo you ask? Well let me tell you from my perspective what Thermo is….

Just a week before MAX I was finally wanting to write my first project completely in Flex Builder. This was a really really frustrating thing from a design standpoint. I would be what the industry is referring to as a “Devigner” Half Designer / Half Developer. I can write some code when it comes down to it and I really enjoy figuring out the functionality of an app but I have always done all my sites or apps in the Flash IDE and laid them out in Photoshop before I move everything over to Flash for animation and coding.

When it comes to doing a project by setting up your design in Photoshop and then getting that design into Flex Builder….. well …. let’s just say it. IT IS A PAIN IN THE ASS! As far as I am concerned.

Now what is this new Thermo app mean to me you might ask? Well imagine combining Flex Builder with a visual design tool. Kind of like Flash with out the drawing tools and such.

In the Demo Adobe showed how they had a really nicely designed Photoshop layered comp. Once they launched Thermo they were able to choose the template they wanted to design there app around. In this case it was a comp from photoshop. Once you choose your PSD file you are able to view the layers in a dialog box just like the import dialog that you get in the Flash IDE. Choose your settings for each layer if you like and Boom all your assets are put on a stage that looks kind of like the design view in Flex Builder. Also over to the right you get a view of all your layers. Kind of like the layers view in Photoshop. We took a photo of the app in it’s present stage of production. Sorry for the image quality. The adobe example was showing the design and development of a music browsing app.

Thermo At MAX

Click for Full Size

When you switch to code view you will see code that is MXML code. Adobe explained that the code view is just like using the Flex Builder interface. You will get all the code hinting and power of editing code that you get by using Flex Builder.

Another really cool example that Adobe gave during it’s demo of Thermo was the ability to click on graphical layers or text layers and change them into functional Flex components on the fly. A great example of this was a graphical scroll bar that they had designed in photoshop. Basically consisted of two layers. You had your background square that looked like the track of the bar and the scrub bar that was also a darker square in photoshop. They where able to select these two layers in Thermo > Right Click and tell Thermo to change these layers into a horizontal scroll bar. As soon as they did this if you switch to code view you where able to see that Thermo had rewritten all of the code to tell the app that these layers are now the functional scroll bar. To spare you more reading there where some other graphic and text areas they where able to click on and convert to other components in the app.

Just a week before I was trying all kids of ways to do this same thing. I was laying out my design in Photoshop, taking it to flash to create my MovieClips, then exporting all my assets as a SWC file to use in Flex Builder. This is a really cool thing being that Flex Builder will treat your assets in the library as Components so that gives you great code hinting. The down side of this for me is you can’t just drag a new “component” out of your SWC file and place it on the stage in Flex Builder. Thermo on the other hand will give you a viual representation of where the button or graphic is located and you can drag it around and move layers how ever you like. As a “Devigner” This totally rocks. I think even hardcore code head developers will find this to save them a lot of time.

Look for Thermo next year sometime at or you can check back here on my blog. I am so excited about this product that I am sure I will be talking more about it as Adobe relases more information about it.

7 Reasons to Hire a Local Webdesigner

I thought I wrote about this before but I can’t seem to currently find the post. A bunch of chiropractors were gathered around my ubuntu running laptop a few days ago and someone asked me the question I’ve been asked some thousand plus times before. Who should I hire to build my website? My first response is always “don’t hire me” because I’m far too busy doing other things (like making posts about cheeseburgers). For those of you non chiropractors that have ended up here seeking local webdesigner advice this will likely be helpful to you as well (especially if you run a local small business).

Seven Reasons to Hire a Local Webdesigner

  1. They are local: This may seem all too obvious but it’s number one for a reason. I’ve done outsourced websites (built in other countries or at least not made locally) and you may have heard stories of how much money you can save by doing so. After having several websites created I can say that the potential savings are just not worth it for the individual or small business when creating a single web site. Going local is nice because you get to meet the person you’re working with. They can come to your office and you can potentially visit their office.
  2. They know your community: Assuming your web designer has lived in your community for some time they should have a good understanding of the neighborhood. This is something that’s often overlooked but it’s become really important for small businesses hoping to capture the local search market. It’s my experience that your local web designer is going to be more familiar with things like zip codes, major landmarks, neighboring cities, and will generally have a better feel for the geographic area your business serves.
  3. It’s easy to check referrals: Hopefully your local web designer has already completed other projects in your community. Not only can you check out those projects online (like you could in nearly any case) but you can also visit the local businesses that employed your potential web designers services and ask what they thought about the experience. Nice way to network too.
  4. Promoting your business locally off-line: (this one’s really valuable) Chances are your local web designer is going to want to show off what a great job they did on your web site. You’ll potentially be the small-business owner that people will desire to visit when the topic of referrals comes up. In my experience it never hurts to get face-to-face with more local business people, even if it is to discuss websites. Think outside the box for a moment here and imagine the possibilities if you and some of your local business buddies linked to each other’s websites. (that’s really an online idea but it works better if you ask local business owners off-line)
  5. Promoting your business locally online: It’s likely your local web designer has their own website (and I bet they have more inbound links than your website) and they’ll probably want to display a screenshot of your web site along with a link to show examples for future clients. That’s a big plus for you since they are delivering you local traffic!
  6. You are supporting your local community: You can electronically transfer your funds overseas or waste huge amounts of money on companies providing cookie-cutter template type sites for your industry or you can support a local, talented, artistic and often times independent web designer. “Made in [Your City]” adds a neat touch to a local site. I can tell you right now the outsourced project is not likely to provide you with any links and worse, the company giving you a template will likely suck your pages right out of search engine rankings by keyword linking back to their main web site (without telling you they’re doing so).
  7. They have other valuable ideas: Your local web designer is likely to know at least a little bit about search engine optimization. If they don’t (and even if they do) they’ll probably have better local connections for other Internet related services then some non-personal company. They could potentially become a resource for you when it comes to other topics such as e-mail newsletters, calendars, online promotions, web site updates, photo accounts, and a number of other areas web designers are typically knowledgeable of.

OK, there are my seven reasons to hire local web designer. If you have more feel free to post your comments. Local web designers, you are welcome to use this article as long as you provide a full follow link to it.