Category Archives: Design

My Very Own Wall of Shame

By Chris Bartek

I got to thinking today about all the trends I’ve shamefully exploited in my years as a designer. It’s not that I was trying to be trendy (actually I’ve never been into following trends), but that in the real world, you have to be competitive with other websites, and your clients often want to be trendy. When you look back through the years, it’s pretty amusing. Ladies and gentlemen, may I present to you (yet another) nostalgic blog post that nobody will find interesting.

Notepad & Netscape Era (RIP 1994-1997)
During this time, nobody really built websites in Photoshop. Typically, you built the website first using Notepad, then spread around some graphics you made in Paint Shop Pro regardless of how well they fit together. Perl, or at least CGI, was pretty much your only backend option, and servers weren’t fast enough to run every page of your site like that. Javascript was around, but wasn’t very compatible in IE, there was no DOM, and so it didn’t really do much. Frames were extremely popular.
As far as design, there really wasn’t much to speak of. Graphics were mostly an afterthought, as images, backgrounds, and fonts had just been introduced to HTML. Usually there was a heavily-compressed banner, a tiled background, an “email me” icon, and would be it. Comic Sans and Arial were the only alternatives to Times and Courier (and we liked it!).

Tables & Photoshop Slicing Era (RIP 1998-2001)
At this point, Photoshop was becoming the standard for web mockups. However, due to limitations of CSS1, we would slice up the images in Photoshop, then export them directly as tables. As far as I know, you can still do this in Photoshop, but nobody is dumb enough to do that anymore. The problem with tables, of course, was that it was a nightmare for semantics, and they were a little tricky to edit directly. Also, there was very little you could override with CSS.
During this time, the dark “cyberpunk” look was huge. Backgrounds were almost always black with white or neon text. It was also popular to use Japanese text for no reason at all, both as the cyberpunk look and because anime was at its peak of popularity. In this era, we found ourselves spending more time editing the website in Photoshop than actually using the HTML. WYSIWYG editors were also popular at the time, but they all quietly went the way of the dinosaur.

Flash Era (RIP 2002-2005)
Also known endearingly as the “Web 1.5” Era. Flash had been around before this, but it really started taking over around this time, stemming from cross-browser frustrations and a desire for interactivity that Javascript, at the time, was incapable of. Flash moved on from splash screens and menus to running entire websites. This of course was bad SEO, but nobody cared. We all spent our time in online arcades playing Flash games. Video was finally working on the web using Flash.
Throughout these years, the designs were typically flat-shaded, abstract Illustrator creations (like what you’d see on a hipster t-shirt), as well as Photoshop manipulated people and landscapes. It was common to see art that was complicated and “overprocessed”-looking.

Web 2.0 Era (RIP 2006-2009)
Although Flash was still being used sporadically, this was the first real coming-of-age for web design. Javascript frameworks started becoming more prevalent. IE5.5 was dead and CSS2 was now much easier to utilize. Table layouts were officially dead. XHTML was the new standard, and AJAX was the new way of hooking into the backend. Tons of new backend languages were being introduced. The iPhone introduced a new way of thinking about mobile websites. The headset hottie was behind every corner.
Because most of the designs in this era were running in CMS’s now, and CSS2 still didn’t enjoy 100% support, websites were incredibly clean and simple. Backgrounds were always white, and the glossy glassy gradient look was popular to say the least. Also, nearly every website was a wholesale ripoff of Apple’s. Flash started dying out during this time due to many factors, the biggest factor being it was not allowed on Apple devices, so it was no longer the silver bullet for animation it once was.

Framework Era (RIP 2010-)
During this time, designers were growing impatient with HTML5’s slow adoption, and decided to take matters into their own hands. In order to get HTML5 working in all browsers, however, it required your Javascript framework of choice and polyfills such as HTML5Shiv or Modernizr. Also during this time is the adoption of CSS fonts, CSS preprocessors, CSS grid frameworks, which led to the popularity of boilerplate templates such as Twitter Bootstrap to ease the installation and integration of all these crazy add-ons.
Designs that dominate in this era are the handmade/indie movie poster look, cut paper look, and stitched leather look. Which is ironic considering the frameworks are now doing much of what used to be done “by hand”.

Predictions
Since these trends all seem to come in 4 year blocks, I predict 2013 will continue in the Framework Era, keeping the same indie look with handmade sketches and shiny happy animals all over the place. Trends such as the “massive wall of text” and “giant photograph” look will continue to get popular. In 2014, I expect to see a new era in which canvas, SVG, and retina graphics up the ante, and some library may come around to tightly integrate Javascript on the front and back, allowing a much more application-like experience, like where we left off during the Flex days.

Leave a reply

jQuery Image Slideshow

By Chris Bartek

Ever wanted or needed to make a slideshow system like you see on news websites? Here is a simple HTML/CSS/jQuery template to help give you a jumpstart. Here are some of the features:

– JSON-based input
– will handle a mixture of horizontal and vertical images of any size
– image descriptions can contain HTML tags
– navigate slides using buttons or arrow keys
– view and jump to slides visually
– automatic advance button
– shows thumbnails when hovering over slide buttons
– responsive layout (for mobile and iframe widgets. Non CSS3-based so it works in IE7 and 8)
– tested in IE8, FF, Chrome, Opera
– lightweight and easy to modify

I started working on a fullscreen mode for it, but got frustrated with the spotty browser support. I hope to eventually come back to that feature… but at any rate, here it is in 1.0 form. You can use it in your projects, but if it’s commercial, be nice and put me in the credits.

(DOWNLOAD COMING SOON…)

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

Thoughts on Flash

By Chris Bartek

Yeah, I know I’m a little late to this discussion.

It’s been two and a half years since the famous Steve Jobs letter, and the web has definitely seen some changes because of it. jQuery has replaced most of the incidental interactive uses of Flash. Many canvas IDEs have started popping up on the market, though many are in their infancy. Video and audio tags have become popular fallbacks for Flash video, though they have not replaced Flash due to H.264, MP3, and IE8. Some tools, like Google Swiffy, exist to help facilitate the conversion of assets from Flash to HTML5, though they are slow and rudimentary. IE9 marks the return of Microsoft finally taking web standards seriously. Nearly all games are still made in Flash, but everything else has seen a significant drop in Flash use.

Bottom line on all this? HTML5, as a Flash replacement, has gained some real momentum, but it is still woefully lacking in most ways. A/V tags have caught on as fallbacks only, if at all, due to the standard’s inability to support DRM technologies and fullscreen modes, as well as the spotty format implementations that cause some serious production considerations. jQuery, though a great replacement in many ways, lacks a lot of the advanced keyframing, masking, 3D, etc. that really made Flash captivating. Canvas, though growing by leaps and bounds in Webkit, is still unsuitably slow in most web browsers and mobile devices, often incapable of a consistent 30fps for games that would easily get 300fps in Flash. The latter begs the question: is the V8 Javascript runtime the savior of HTML5 like we think it is, or is there still more work to be done? A lot more?

Here’s a real world scenario for you. You have a client with an animation and video-intensive project for you. They want it to run on IE8, Firefox, and iPad, among others. Simple, right? Well, no. here’s the situation. IE8 has no canvas support. iPad has no Flash support. What technology do you use to create the animations, and what technology do you use to play them? Guess what, I’m faced with this problem right now, and many others have also. The answer usually ends up being, you can’t use animation, and you have to double up on video formats. For this particular project, not using animation wasn’t an option, so the solution we came up with was: Flash as an animation IDE. Swiffy to create HTML5 fallbacks. Flash and H.264 for video, canvas as a fallback, Flash as the fallback-fallback for absence of H.264 support. Why is this so stupidly complicated for such a simple thing? Microsoft and Apple, that’s why.

As much as I dislike Flash, I don’t really see it going away anytime soon. More like what happened to Java applets; you see fewer and fewer as better technologies become more capable of replacing it (Flash). This is already happening with Flash, but Flash is still a lot more suited for certain projects at this time. Just off the top of my head, here are a few pointers canvas could learn from Flash:

  1. IDE is king. Flash is two things: a runtime plugin technology, and a development environment. Canvas currently has no de-facto, and what is available is not fully-baked yet. Creating animations in Flash was so easy. In canvas, it usually means a Javascript nightmare to get something awful-looking.
  2. Sub-pixel accuracy. This was in Flash from the start, and so well-integrated it was a little annoying. But useful. Maybe this can be done in WebGL at some point, but right now I don’t think it’s possible.
  3. Speed. Really, this should be at the top of the list. Speed, people. Get it together. We want fast frame rates. No tearing. No lag. No major browser inconsistencies. If there’s a problem with Javascript, then it needs to be solved.
  4. DRM. Sure Javascript can be obfuscated, but there needs to be ways to protect media from getting jacked, if so chosen. This is easier said than done with the way the internet works, and I’m aware of that, but it would be nice.
  5. Asset containment. It would be nice to be able to shove all data into a single binary, instead of having PNGs, MP3s, etc. scattered all over your server and needing to be downloaded individually. Maybe the canvas IDEs of the future will have the option of base64’ing everything, but that may make the problem worse (filesize and whatnot).
  6. A/V synchronization. Flash can be easily synced so that animation and music don’t go rogue. Also, ways to read audio levels to make interactive queues, and ways of generating custom audio during runtime. Not sure if there’s a way to do any of this in canvas. Doubt it.
  7. 3D. Okay, so WebGL. The other browsers need to get with it, because Flash seems to be years ahead on this. How it will compare to Flash remains to be seen.
  8. A common binary runtime. This is the only way canvas will ever be nearly as fast as Flash. Right now, your runtimes have to be written in Javascript. Every IDE has their own. What if there was a binary runtime to hook into, that every browser supported? Oh wait, I guess that’s what Flash is, and what canvas will never be. Heh.
  9. Compatibility. Not really canvas’s fault, but not even half the web supports canvas. IE8 and below, plus mobile devices are still far behind… and when they do support canvas, they’re too slow. Flash, even if its mobile forray was short-lived, at least had a faster implementation than canvas.
  10. Camera and microphone support. Seems like Chrome might implement some of this, but as far as I know there are no common APIs for this like there are with GPS.

And I could go on. Some of it is nitpicky, I know, but a lot of it is incredibly important to designers and animators.

Bottom line, it’s unfortunate that the late Steve Jobs felt it necessary to start a war over two technologies that aren’t necessarily mutually exclusive. In a way, I’m glad Flash has gone back to what it’s supposed to be (a runtime for when performance, presentation, compatibility, and heavy dependence on animation and object-oriented programming), but it saddens me a little to see the web step a few years back in time, in order to bend over backwards for mobile devices. The result seems to be that the web is a more boring place, and canvas so far has failed to solve the basic problems it claimed it would.

Here’s how I see the future. Eventually, Adobe will make Flash capable of compiling to canvas directly. That way, canvas will be available as a fallback for when Flash isn’t available. If that doesn’t happen, eventually converters will get better, or Adobe will come up with a new IDE. And no, I’m not talking about Edge, Hype, or Muse. Please, Adobe, no more garbage toys; give us what we want. But anyway. At any rate, we’ll likely continue down the path of Flash really finding its niche, and browsers continuing to offer no real solutions to canvas’s shortcomings.

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