Category Archives: CSS3

Fantasy Healthcare

By Chris Bartek

I have an announcement to make: I placed 3rd in the Robert Wood Johnson foundation’s Games to Generate Data Challenge. I have been secretly working on this project for most of the year, and now that it’s over, I can talk about what I’ve been building.

Fantasy Healthcare is a game that allows friends (in the Wisconsin area for this version) to create their own healthcare provider dream team and pit it against other friends and players online. The provider data and provider names are 100% real, but the doctor/department names have been changed to protect the innocent. The idea is that players will better familiarize themselves with providers in the area, while also learning which providers perform best in certain areas.

The interesting part of all this is how it all got started. At my public sector job, I joined up with a group that was looking to enter the Games to Generate Data Challenge as a team, but alas, government red tape (and lawyers) prevented this from happening. However, since I was a contractor, I was able to take an idea of my own into the challenge and see how far it would get. It ended up being a good enough idea to place in the Top 5, so from there I developed the game on my own.

Fantasy Healthcare is written in HTML5, Canvas, CSS3, Javascript, jQuery, jQuery Mobile, PHP, and MySQL. The back end stuff runs on a Linux server. The Canvas stuff is also cross-compiled to native iOS and Android platforms for the efficiency and fast performance you expect from a game. I did it all myself, so considering I competed with some large teams and some big industry players, I guess I did pretty well for 3rd place.

So besides winning some nice prizes, I also got a trip to Boston to attend Games for Health, and a trip to the Health 2.0 Conference in San Jose to see the winner announcements. First off, Ben Sawyer’s Games for Health project in Boston was a wonderful experience, and I wish I were able to go again. There are really some amazing interactive ideas out there ready to transform the industry. As far as Health 2.0, I also had a great time hanging out in the Valley, drinking local brews and eating some In-N-Out Burger. The 1st and 2nd Place winners were totally deserving of their prizes, each having some fun-looking and interesting games, and I sincerely wish them all the best with their endeavors.

While I was in San Jose I got caught up in the government shutdown, but that’s a story for another time.

The Robert Wood Johnson Foundation and Health 2.0 are doing some wonderful things right now to provoke and promote bleeding edge ideas in the healthcare industry, so be sure to visit their challenge site.

What’s next for Fantasy Healthcare? I’d like to publish the apps and expand it to more cities. This will take some time I don’t have at the moment, though. In the meantime, it is available here for anyone to play with.

Leave a reply

Icon Fonts: The Vast Wingding Conspiracy

By Chris Bartek

Icon FontsThe latest trend in web design is to use fonts to do render glyphs, in place of the img tag and the still-elusive SVG. I’m sort of on the fence about this, although I recognize there are definitely some good reasons to do this. Instead of blathering on about theory, let’s go to the chalkboard, shall we?

Positives:

  1. Less messing with Photoshop and/or sprite sheets
  2. Load images faster
  3. Advantages of infinite scaling
  4. Advantages of CSS (shadows, hover, etc.)

Negatives:

  1. Limited to the glyphs in the font
  2. Limited to font limitations (no color, no texture, etc.)
  3. Bad semantics
  4. Potential for bad 508
  5. Potential for bad SEO
  6. More verbose than img tag
  7. Potential to cause your site to suffer “Wingding Syndrome”
  8. Necessary to load an external font, including hundreds of icons you won’t be using
  9. @font-face, and the baggage that comes with it

Hmm. You know, I was actually meaning for this article to sing the praises of icon fonts, but I’ve suddenly changed my mind. Instead, we’re going to have a fair and balanced look at the above. So without further ado, let’s pit the two technologies against each other…

Logistics
The less dealing with Photoshop for icons, the better, right? Well don’t forget that you’ll also have to deal with font creation software instead (gross) unless you want to use stock images for your icons. That’s fine, except we went down this route in the ’90s with Wingdings 1-3. I still have nightmares to this day.
Also, don’t forget you will need to store and serve several copies of the font. The IE version, FF version, Chrome version, mobile version etc.
Winner: images

Browser and Loading Time
In theory, vectors will load faster than a sprite sheet, right? Here’s the thing. A font is a giant sprite sheet already… well, a vector sheet, but a sheet nonetheless. You might have a 20k PNG representing your icons, but you might have a 60k font representing tons of glyphs, 90% of which you will never use. But let’s say the font is smaller. So it’ll load faster, right? No. Custom fonts can take a few seconds to install, etc. before being applied to the website. In the meantime, you’ll have random letters sitting around you page while it waits for the browser to do its thing. Is it worth it?
Winner: images

FX Advantages
What has always sucked about CSS is the lack of support for image effects. You cannot add drop shadows and change colors (at least, not in the way you’d expect). With glyph fonts, now you can. So I’ll concede to fonts for this, but the question I want to leave you all with is… why do you need to be able to have hover effects and shadows on your glyphs?
Winner: fonts

Scaling
This is another brilliant argument for font glyphs. Img tags are bitmap only at this point, and adding retina resolution is a huge pain and there is no best way to do it.
Winner: fonts

Semantics
You need to add an icon to your page, which is more semantic: <img src=”email.png” alt=”Email:”> or <span aria-hidden=”true”>&#x25a8;</span> ? Yeah. And what do you do about those with visual impairment?
Winner: images

SEO
How do you think Google feels when it has trouble reading your website? You know that friend of yours that uses Outlook and the smiley faces turn into letters in your email client? J
I know you can use “content:” in CSS, but that’s not going to save you from Google, and “content:” is something you should always strive to avoid using. And it may not be happening now, but eventually black-hat SEO companies could start using ROT-13 rotated fonts to hide stuff they don’t want Google to necessarily see. I don’t think they’re doing it now, but there’s that possibility they’ll spoil the fun.
Winner: images

This reminds me of when we were using Flash and Javascript to render custom fonts 6 years ago. It’s overkill. Wait for SVG, and in the meantime, just deal with bitmaps unless you have really good reason to use this method.

In closing…
Don’t. Just don’t. Unless you plan to build an obnoxious website with tons of glyphs all over it.
Which you shouldn’t.

Leave a reply

Project Workflow for Lone Developers

By Chris Bartek

I’m not ashamed to admit I’m a designer-developer hybrid. I worked as a graphic and web designer for several years. I did back end development professionally for 4 years. I’ve done UX development professionally for 3 years. I love design and I love coding, and I love doing both at the same time. So it’s not uncommon for me to build entire web applications by myself. This practice gets a bad rap because developers are typically awful designers, and vice-versa, but for me it comes naturally.

I’ve been designing since age 6 and programming since age 11, and never quite knew how I could merge those talents. Since kindergarten, everyone always told me I would grow up to be an artist, but I wanted to be a programmer. Once the time came when I needed to choose a major, I chickened out at the last minute and chose multimedia (I hated math and still do). Back in 2001, CD-ROMs and VB were king, and Director and Flash were still in their heyday. That was how you built interactive applications. But slowly, web and mobile took over this space, and bridged the gap between design and development. I was lucky to be caught in the middle of that merge.

Throughout the years, I’ve typically been unmanaged throughout the web development process, since the stuff I do is usually highly experimental. Because of this, I’ve developed and refined my own process for development that seems to work great for me. Your mileage may vary, but I’ve found this workflow to be the winning combination, especially for projects where I’m going it solo.

Lone Developer Workflow

  1. “Liveframing”, what I call wireframing with HTML. Create a preliminary GUI with no design, just basic structure. I prefer this to wireframing in most cases… honestly, I’ve never been a fan of wireframing tools, and I avoid them whenever possible. It depends on the project though.
  2. Mockup. Based on your liveframe, use Photoshop to design what the final website will look like. You want to throw a bone to the client to keep them busy awhile, but you also want to put a vision in your head of what you’re working towards.
  3. Database schema. This is the third thing I usually do, for two reasons. One, after building the GUI I have a pretty good idea of what data I’m collecting and how it will be used, and second, I want to do this before starting on the back end. I usually use Excel or pen and paper to draft a schema, and then build the actual tables as I need them. The schema will always change from start to finish, but usually I nail it with 90% accuracy. And usually, I end up needing fewer tables than I had originally schemed.
  4. Back end development. Once I have a barebones liveframe and a schema, I’m ready to start back end development. Of course I start in the planning stages, figuring out which pages do what, how the API will work, .htaccess considerations, etc. and generally decide how communications will be coded. Communication formats will also be decided in this stage (XML vs JSON, data structure, REST considerations, etc.). Then, I start coding, and hook the liveframe up to the code as I go for testing purposes.
  5. UX development. I start elaborating on the liveframe by adding the necessary Javascript and jQuery.
  6. Test, test, test. As I move through my prototype on the front and back, I add or modify decisions for both sides. The pieces slowly come together. The client should be engaged during this time to verify the project is functioning under the proper requirements.
  7. Once the project is 90% solid, then I start slicing the front end. The liveframe’s header, footer, and CSS will be replaced with the new design, and if you did it right, it should pop right in.
  8. Beta and QA testing. This is probably something you don’t want to do yourself. Find friends willing to test it out.
Leave a reply

Let’s Talk about Pre-Processors Like it’s 2010

By Chris Bartek

Reading some of my past entries, you’d think I hate pre-processors or something. Well, that’s not quite right. Setting aside the obvious (PHP, etc.), I want to have a quick discussion on the pre-processors that have been popular over the last few years, and my take on them.

SASS & LESS
Great ideas, but pretty much the same thing. They don’t offer any real benefit over old-school CSS for small projects, but they’re certainly useful for the larger ones. But you know what’s better? Stylus. Stylus seems to take the whole idea a step further with the whitespace syntax.

CoffeeScript
Mixed feelings. I used it on a project recently, and while I love how easy it makes OOP and the syntax is lovely compared to the mess that is Javascript, it seemed to have a few frustrating quirks, and whitespace syntax is not always your friend. But then again, it beats getting lost in the “});});” forest. Debugging can quickly become frustrating as well.

HAML
I won’t lie, I can’t stand HAML. I want to like it, but the fact is HTML, like XML, is incredibly well suited for, well, markup. Here is an example of the number one reason HAML drives me nuts:

HTML
<span class="test">this</span> <strong>is <a href="test/" target="_blank">a</a></strong> <em>test</em>

HAML
%span.test this
%strong
  is
  %a{:href => "test/", :target => "_blank"} a
%em test

…so what happened here? Well, I traded a simple, common line of text for a mess of carriage returns, indents, hashrockets, and… colons? why?… and at the same time made it more difficult to read. I saved 20 characters, but at the expense of readability, and I made my brain hurt. HTML. Isn’t. A. Programming. Language. The verbosity of XML serves its purpose, like it or not. Although like everyone else these days I use JSON over XML most of the time, when you are dealing with lots of inline data, it makes more sense to use XML instead. Repetition and verbosity != not readable. This just doesn’t seem like the solution to any kind of problem HTML might have had. A better solution? Stick with HTML, and for templating, use mustache.js (the only Javascript-based templating engine that doesn’t suck, in my opinion).

Oh, and if I ever said anything mean about Node.js, I take it back. Without that, none of this would be possible. 🙂

Leave a reply

Presenting my latest project, SoulTrade

By Chris Bartek

As you might have guessed, I’ve been working on another app these past few weeks. This represents only 2 weeks of work, so overall I’m okay with how it turned out. Without further ado, I present:
SoulTrade (soultra.de)
(available for iOS and Android!)

What is SoulTrade? It’s a market for buying and selling souls, basically. Yeah I know, it’s a pretty stupid idea, but I mostly just wanted to flex my design and development muscles with some of my free time. I really didn’t care what the website did, as long as I got to use PHP/MySQL/jQuery/Javascript/HTML5/CSS3. So ironically, this project really has no soul, heh.

Technical details: SoulTrade was written by me in 2-3 weeks with a PHP/MySQL back end using my own framework. The front end was designed by me in Photoshop and Dreamweaver, and of course utilizes HTML5/CSS3/Javascript/jQuery. The website is running on a LAMP stack, while the mobile version is using jQuery Mobile and Phonegap.

Enjoy.

…mwahahaha….

Leave a reply

Common Sense By Any Other Name…

By Chris Bartek

Seems like these days everyone gets to give a brand name to common sense, obvious practices. OOCSS, for instance… using DRY principles with CSS, come on, that’s just good practice. SCRUM… “let’s have meetings to discuss what’s progressing and what has problems–nobody’s ever thought of that before!” And then silly ideas from ages past, like sIFR and Cufón, the ridiculous answers to problems that weren’t really that huge of problems… well, those weren’t really common sense, more like the opposite, really. Since people like Inman get their 15 minutes of fame for thinking they’re the only ones that ever thought of using Flash to embed fonts, perhaps it’s time I came up with the Bartek Web Design Philosophy. I’m gonna make this up as I go…

  1. Be as semantic as possible. Let everything be what it is, and the universe will stay in balance.
  2. Validate your HTML. If it doesn’t pass validation, and you don’t want to let go of the code that’s causing it, you should probably rethink it. If you truly love Chromeframe, you must let it go free.
  3. Don’t bother trying to get your CSS to validate, except to look for syntax issues. You’re only going to hurt user experience trying to settle for the lowest common denominator.
  4. Use HTML5, but use it like it’s XHTML5. I know it’s a glimmer in the W3C’s eye right now, but you’ll thank me in 5 years.
  5. Polyfills are your friend. CSS PIE will help you achieve enlightenment, even though it has its dark side.
  6. CSS and Javascript do not belong in your HTML. Ever.
  7. jQuery, jQuery UI, and jQuery Mobile. Through this holy trinity, you can accomplish all things.
  8. Wireframe if you feel it is necessary for your clients. Mockup and slice with Photoshop. Don’t start any HTML/CSS without a full mockup.
  9. Don’t over-engineer. There’s no point in going nuts in Javascript for Aunt Edna’s Doll Furniture Emporium.
  10. Load as few external files as possible. Don’t have an external print stylesheet, 50 icon files when you could have used a spritesheet, or a dozen jQuery plugin files that never get touched, that could just be merged together.
  11. Don’t be a slave to backend devs. Pick a language, and learn it. It’s not as hard as you think.
  12. The best solution is almost always a custom one. It will save massive headaches in the long run.
  13. Don’t get caught up in design fads. The homemade look will one day be just as tiresome as the glossy “web 2.0” trend from 2006.
  14. Experiment with new stuff, and don’t be afraid to use Flash if absolutely necessary, but always have a fallback plan.
  15. Make your layouts responsive, but remember this is not always the answer to all mobile user experience problems. Sometimes jQuery mobile, etc. will solve this.
  16. Always plan for IE7 and IE8. Use IETester. IE6 is burning in hell, so no worries there.
  17. Be smart with your SEO. Don’t overdo your SEO, or you will find your SEO fighting an uphill battle it will never win. But if you have a serious budget for SEO, then by all means. SEO.
  18. Don’t settle being employed by ad agencies and web marketing companies for years on end. They help build your portfolio, but are career dead-ends. Keep pushing yourself further.
  19. The quality of your database is directly proportional to the quality of your backend. If you find yourself doing stupid queries, you probably have a stupid schema.
  20. Know a little of everything, find what you like best, then specialize.

And I guess 20 is enough. This philosophy evolved over 7 years of doing this professionally, and has served me pretty well. Hope someone out there finds this useful. And remember, it’s not just common sense… it’s the patented Bartek Web Design Philosophy®.

Leave a reply

Your Favorite CSS Grid System is Garbage

By Chris Bartek

There. I said it.

Like most designers, I started tinkering with grid systems such as the mysteriously popular 960.gs back in 2011, and early on, I felt like there was something deeply wrong with the whole concept. For starters, semantics. With all these systems asking us to place all these bazillion class names all over our HTML, surely we’ve all stopped and scratched our heads any wondered why we ever crawled out of the primordial ooze of table-based layouts, only to let CSS devolve back into the very thing we hated (merge of layout and content). Let’s not kid ourselves, this code is not clean, and it’s not semantic. Try to work it into a responsive layout, and you’ll really see what I mean.

Which brings me to the other problems: most of these grid systems lack responsiveness, or heck, some even lack basic fluid capabilities. Sure you can shoehorn it in, maybe, but then your class names will suddenly make even less sense than before. If these CSS grids are the future of web design, maybe I’ll just go back to tables, heh. All they seem to do is make your code less sensical, your layout less flexible, and for what, exactly? To bring us back to the glory days of rowspan and colspan? Ladies and gentleman, Photoshop is your friend. Set up your columns in your mockups, slice from there, and you’ll have nothing to fear. Stop treating design like it’s programming.

Okay, so I’m oversimplifying things, haha. To be fair, CSS grids are a good solution for certain projects. Form-heavy sites. Heavily CMS-generated sites. Sites that won’t need much mobile treatment (or have a separate solution like jQuery Mobile). And also, I haven’t mentioned this yet, but there is a light shining in the distance… from the darkness, a new era of CSS frameworks has emerged, and I rather like it. Of course, I’m talking about Semantic.gs.

If you haven’t heard of this yet… take a look. Semantic. Responsive. Fluid. I was blown away. The secret is they’re using LESS, etc. to do the heavy lifting, and the end result is surprisingly tolerable. I… wow… I *like* this solution. The CSS preprocessor requirement, of course, has advantages and disadvantages on its own, but if your next project is suitable of using LESS / SCSS / SASS / Compass / Stylus / CSSPreprocessorFlavorOfTheWeek or is already using it, give Semantic.gs a try (if it supports your preprocessor). She’s pretty and smart… not like all the other girls.

I’ve also noticed Twitter Bootstrap is attempting something similar, but it’s, well, just like everything in Bootstrap, the implementation is too vanilla and inflexible. That’s right; I went there.

Leave a reply