dev /
Talking web dev, making of
OK, so I made this website and people ask me how. The short version never helps and the long one usually bores. But let's see if we can make this interesting by splitting it into sequential sectioned parts. This is the first.
The aim here is not to hand out reusable code, but a precise case study on what has been done for particular needs and specifications. Examples and insights that might inspire you to develop other custom solutions in the future.
Some of the approaches could indeed be the subject of nicely wrapped components, however, as previously mentioned, this topic is not about ready-to-use solutions, but rather improvising; which I consider to be the developer's true weapon.
From the top
I usually prefer dropping a feature than a detail.
If you know me, you pretty much know I'm a sucker for reinventing the wheel. I know it's there, but I just like creating stuff. That's why the sole purpose of many personal projects of mine is development itself. But this time there was a twist.
I first had this idea that I liked and—just like before—an infinite implementation time frame. But then I found out about an inconvenient development, an unforeseen medical condition that was supposed to compromise the next unknown period of time. Suddenly this idea became a goal.
I wanted it done, and I wanted it done in two weeks. Working after hours, not more than 3-4 hours a day. Considering that the previous version spanned over months of passive, on and off development, this was a serious challenge.
Surprisingly, it turned out to be success. It took a few extra days to receive feedback and fix minor bugs, but the outcome was positive. The key factor was being able to take on-the-spot decisions about what goes in and what goes out. Either quality or quantity, one inevitably gets compromised if you want to get something done. I usually prefer dropping a feature than a detail.
So here's the most I could get out of this tight time frame. And just to make sure we're on the same page, I'm talking about an everything-from-scratch sequel to my previous blog. Its development included everything from visual idea to server deployment.
Layout
Having a more creative approach without leaving my comfort zone.
The first thing I knew was that I liked the current (now previous) clean post display, but the surroundings (header, menu, sidebar) sucked. That poor background gradient just had to go and at that point I was already thinking about having a fullscreen blurred-out image in the back. But the fact that I also already had an image attached to each of the posted articles made it possible.
This was very convenient because I could never choose one universal image to stand for everything I'll ever write about. Or if I tried to, it would probably end up being the color gray.
Or yes, the colour grey if I had paid any attention in English class.
Not having traditional design skills, I build my layouts using only slightly colored boxes and various sizes of text to fill them with. Which is OK, because I'm a big fan of minimalism and typography. But that's not always enough.
So having these backgrounds as part of the content and not the layout is like a loophole in my technical ways of designing interfaces, therefore having a more creative approach without leaving my comfort zone.
This is very helpful when you're trying to meet a short deadline, but you should leave your comfort zone as many times as possible otherwise.
The little things
Rounded corners are like the F word.
A change probably nobody would bother talking about is switching from center to left alignment. It just seems like the natural choice for me; maybe because deep down I always knew that on a binary level centering takes more computing to render.
This also allowed me to separate the controls from the article and effectively have a window-wide liquid layout, with the comment grid filling up the empty spaces in between. (check out the Dragdealer post to see the grid in its glory)
By now the the article was clearly the focus of the page. But there were also general guidelines I had to take into consideration in order to improve the reading experience:
- High color contrast. Almost black and white in my case.
- Increased font size and line height. Display densities skyrocketed over the last years.
- Generous paddings and margins. It's what we call clean.
- Adaptive layout, compatible with the native browser zoom.
- No over-the-top meta data; nobody needs to know the exact hour an article was posted at.
Lastly, no, I will not have rounded corners just because I can. They might work great for Apple design, but that's not always the case. I always thought rounded corners are like the F word—they come on strong at first, but they wear out in time.
Front-end
Developing by standards and not browser output.
In order to maintain the fast pace I was striving for, I finally took the liberty to practice one of the things I was preaching for a while now, developing by standards and not browser output, that is. In other words, HTML5 and CSS3 without any room for buts (or any enabling script for that matter). Legacy Internet Explorers can kiss my shinny metal ass.
As far as fonts go, most of the time I'm a Helvetica, Arial, sans-serif kind of guy and I strongly recommend using web-safe fonts, especially when dealing with large paragraphs. But not this time. I went straight to Google Web Fonts and searched for a sans-serif font with Extended Latin (because of my exotic name). I immediately saw Open Sans and went with it. I like the contrast given by opposite weights.
When developing websites with basic functionalities like this one, HTML5 is mainly useful just for keeping up with the standards and maintaining a clean structure. But CSS3 on the other hand speeds up the process miraculously. I used to design layouts in CSS3 directly, just so I can then export them into CSS2 compliant styles.
From a designer's standpoint, this is like creating fully-functional interfaces in Photoshop alone. Think about that.
To be continued...
This first part is merely introductory and things will get technical from here on out. Next are: grid and navigation. Subscribe or follow if interested.
© September 2011 Ovidiu Cherecheș
+Reply
Posted December 2011, by Michael M