A Redesigned Culinaria
After a year of thinking and rethinking, designing and redesigning, (and a lot of coding) I’m happy to present the brand new and improved Culinaria. A new food blog site utilizing my custom CMS, responsive design thinking, and more robust logic in terms of the back-end as well as the front-end user experience.
I know it sounds a bit over the top to celebrate a website redesign, but the story of what lead to this point...and the new skills/talents learned from it...made it all worth sharing.
Let’s go back to January of 2012
Originally, Culinaria was my experiment in Wordpress. I wanted to set up and use Wordpress for a site simply so I could be familiar with it and thus be able to show employers I knew what I was doing. I launched the original site in January of 2010 and added new content when I had free time.
Two years and many postings later, I had published an article on an easy delicious dish to try if you’re planning on dieting after the New Year. A few days later, my web host called me to say the website was drastically changed. Instead of the home page, I saw a black screen with a message from a hacker. Someone had managed to use a programming hole in the back-end and thus ripped out the home page and even locked me out of the admin area.
I was extremely upset. I thankfully managed to restore the old website, but this hacking, combined with other problems we were having in the back end, was enough for me. I had been bouncing the idea of a redesign, but this incident now pushed me to actually do it.
No more Wordpress
The biggest change in Culinaria has been a divorce from Wordpress. For the record, I did regularly update the Wordpress back-end through the Admin area, but the hacker apparently found a weakness in that many older files were not erased and replaced in these updates.
The new Culinaria fully utilizes my own custom CMS that I posted months ago (with some new updates). Part of this came about mainly from difficulties other users had with the Wordpress back-end. I had one writer make a complete mess of content when she tried to post it with a formatted recipe, and I even felt the way Wordpress handles content wasn’t up to my personal standards of ease and efficiency.
The new CMS keeps the sections separate for easier organization of the content, and recipes are entered into a separate database table so that content can also be utilized on multiple parts of the site. Even adding in recipes to articles now is handled by simple shortcodes as opposed to dropping in whole pieces of HTML.
The new site is not a "total" or "standard" responsive design (if you're thinking in terms of experts and how they define responsive web design). The layout is not liquid, but more "adaptive" (as I see the term loosely used). I'll be honest and say I'm not a deep fan of liquid layouts I've seen, mainly because of how bland they look. I know minimal is the new trend, but I still like textures and I really did like the old layout of Culinaria. I wanted to keep aspects of the old layout in the new site, like the background texture and colors. I also like having control on how the layout appears in terms of text typography, image placement, and element placement.
My way was to design the site on three major resolution groupings or "breakpoints", like I've done in the past. I made my largest layout to appear beautifully in desktops and laptops, but then the two smaller ones to display in smaller screens (like netbooks) and larger tablets. I continuously tested the smaller layouts on testing platforms like responsintor and even on my own tablet.
What about mobile?
How I handled mobile is again slightly different from the general norm. I've seen the debates on how developers should steer away from having separate mobile sites, but I don't fully agree with that notion. There are ways to tell analytics to mark a visit to a link even on two separate areas. I also am a fan of using a framework like jQuery Moble for smartphones and smaller tablets such as the Kindle Fire.
I've seen developers debate that a responsive design should go all the way down to smartphones, but I don't like sacrificing layout to appease a small screen on a 3G connection. Likewise, I don't want to feed that same device a larger framework of code and images that set to not even appear. The best logic for separation came from bloggers who stated that the user experience is the most important factor, and thus separation can help make for the ideal experience on small screens and large screens. I'm not sure if this will be my permanent way of doing things, but it's more an experiment. Maybe I'll end up deciding to go from desktop to smartphone in my next project. You never know.
In terms of mobile detection, this also changed. I used to use a script that would detect by device, but after searching through many possibilities, I don't like the idea anymore of identifying devices. My goal is to have the more graphic site show up on desktops, laptops, and large tablets while the smaller mobile site appears on smartphones and small tablets.
My solution was to detect based on screen size, but to put detection on both sides of the equation. If you try to open the mobile site on a desktop, it tosses you to the desktop layout. If you try to open the desktop site on a smartphone, then it tosses you to the mobile layout. From a user standpoint, they get the responsive experience, since they can't really drag the browser width on mobile devices. In any case, they see a layout that works for their device every time.
Other aspects to note
One other big change to this site and how I am handling blog sites is the usage of Disqus as my comment system. In the past, I felt as if I should try to keep the comments "in-house", fearing comment systems like Disqus or Facebook would fail. I've realized now that comments aren't just about user feedback, but also about social sharing. I'd see how comments on Facebook systems would then post on your Facebook wall, thus your users are sharing your content for you.
My choice to use Disqus was partially because of how buggy Facebook's comment system is, but also on how much trust users give to Disqus. I've noticed how my blogs see plenty of traffic, but not comments. After research, I found many users simply like how you sign up in one spot with Disqus, and thus the blogs you comment on won't have their information. It makes total sense, hence why I've made the switch, and will even add Disqus to this blog and the D-Jam "Thoughts" blog.
At this point, I'm going to now take what I learned in redoing Culinaria and bring it to this site. I'll post more on this as it evolves. Also stay tuned to the other experiment the Culinaria redesign was about: If you can live without Adobe products.
What do you think of the new Culinaira site? How would you have done differently?