Ok, after what seems like too many late nights I’m finally calling the new theme to Urban Potato done. I call it Granite, and because I have few design skills on my own I got a lot of the ideas for Granite from SquareSpace’s excellent site. Hopefully they don’t mind. This is the first time I’ve built a style from the ground up and gotten it to look like it does in Photoshop. It’s also the first time I’ve done this against someone else’s HTML and I tried really really hard not to modify the HTML generation of BlogEngine.NET. Here, I sometimes failed. I thought it would be useful to document the good and bad parts of the process.
Photoshop Mockups
Nearly all web sites today start as Photoshop mock-ups. Photoshop is a mixed bag. It’s an excellent and flexible tool for building all the graphics you need for the site, but there are some parts of it that are still pretty painful. Here are my major sticking points:
- Font Selection. Photoshop installs hundreds of cool new fonts. Then, to decide which one you want, it presents a fun little combo-box with all of the hundreds of fonts in a list. Great. There’s a “preview” in 10 point type. Great again. You can really see the nuances of each font at ten points. Maybe there’s a better font selector somewhere, but I couldn’t find it. For designing a web site I need much bigger renditions of fonts. I need to see fonts grouped by family. I need to see which fonts are installed on which OS by default. I’d even like to see fonts for other OS’s (eg, Mac).
- Web Slicing. After you build a nice mock-up in Photoshop the next step is to slice it up into images you can use on the actual site. Photoshop’s web slicing tools do an excellent job of carving up a site into very precise images. I found two problems with these tools. First, my mock-up is usually too much of a mock-up for slicing. I needed to convert my mock-up into another set of “component” layers that had the graphics setup in a way I could use on the site. Second, the web slice tools seem to think I want the entire design carved into static graphics. Who does that? Maybe for a fixed layout page with fixed content it’s fine. For me I ended up with a whole bunch of extra useless images generated for areas of the site. I would much prefer manual web slicing with no automatic slices generated. Perhaps this is an option I didn’t find.
- Pattern Generators. Some parts of my site use textured backgrounds. For example, there is a stippled pattern in the top header and some “noise” in the menu at the bottom. It was really easy to create these textures in Photoshop. They even have subtle shadows and highlights on them. But on the web these need to correctly tile as the web page grows and shrinks. Photoshop has a cool tool called a pattern generator that can built tiling images for you. It works, but it took a lot of planning to get it to work right. I found success when I started with a texture and built a pattern from it, then took the pattern and added highlights and shadows to it. The process worked, but it was cumbersome.
Considering those are my major beefs Photoshop worked out pretty well here.
CSS Conversion
Once I had my mock-up, it was time to convert it to CSS for rendering on the site. The tools for this…suck. Really, the best way to do it is to have the site up, modify the CSS and hit F5 to refresh your browser and see what changed. Debugging CSS issues is even harder, but Google’s Chrome debugging tools made it much easier. Here’s an example:
Chrome's Inspect tool
Here, I’ve highlighted the image that I show to represent the primary category for a post. you can see the CSS inheritance hierarchy to the right, showing that the category image is inheriting default images styles for the rest of the images in the post. I’ve got to be careful: if I added a fancy border to the images in the post it would show up here too.
The idea behind HTML and CSS is that HTML provides the document structure and CSS is used to provide the look and feel. In the real world this is a lie. While I tried really hard not to modify any of the HTML generation because I want it to be easy to pick up new versions of the web site engine, there were some places I had to so I could get the CSS to do what I wanted. I either had to wrap things in a div, or I had to add class names to unnamed elements to set them apart from their content. If I had to have any issue with BlogEngine.NET, this would be it: the class and ID naming and document structure is inconsistent. There needs to be more structure around some of the generated HTML so it can be more readily styled via CSS. If the structure that was there was more consistent with naming and usage of the same tags I could have a lot more compact CSS and it would be much easier to understand.
Enabling Mobile
BlogEngine has support for detecting mobile browsers. By default, it doesn’t see the iPhone as a mobile browser but that’s an easy change to the config file. I found out the hard way that making the iPhone a mobile browser is not what I want. I want the iPhone to have a rich experience, and I wanted to be able to administer the site from the phone. I turns out that if you log into BlogEngine while on a mobile site and save administrative settings, it saves the mobile theme as the default theme. That’s not quite what you want.
Instead of treating the iPhone like a mobile browser, I added some special CSS sauce from Apple so I could have a conditional style sheet just for the iPhone. This worked perfectly on Chrome and not so perfectly on IE. It turns out that even the much improved Internet Explorer 8 (which renders CSS muuuuch better than IE 7) doesn’t support the media attribute for links so it always ignored my CSS. Luckily, IE knows it sucks so it provides an “if IE” hack where I can include the right style sheet for IE. Now I have full display and editing support on the iPhone too.
Next Up: New Name?
Now that I’m happy with the UI, it’s time to examine the site’s name. When I named UrbanPotato I had two things in mind: first, I wanted the word “urban” in there because Danna and I live in the city. Second, I wanted another word. Since then, I’ve made up reasons for the name. They’re contrived, and now that we have the Cole Monster, we’re probably ready for a new identity.
It’s hard to rename a site. The site loses all of its indexing on Google and Bing, all your friends need to learn the new name, and all of the other web crawlers will need to be updated. I also run mail server, so all places on the web I’ve entered my personal email address will have to change. Yikes. I think I’ll keep the old names active for a couple of years after the switch…
The technical logistics of the rename are nothing compared to the task of deciding what that new name should be. So far, I have thirty candidates that are (believe it or not) available but no clear winner. And I get new ideas every day. Clearly this could take a while. This time, I’m trying for a little more meaning than two random words jammed together. Wish me luck.