Category Archives: HTML5

Attention Web Designers

By Chris Bartek

Please stop doing the following.

Creating external links without a default target=_blank. You might be against it for whatever religious reason, but this doesn’t change the fact that people expect this behavior. I’m looking at you, Reddit.

Unnecessarily modifying the URL as you scroll through a page or highlight text. This makes me have to hit the back button 20 times.

Loading your title tags up with SEO garbage instead of my location on your page. This doesn’t help your SEO, and it makes tabbed browsing frustrating.

Infinite scrolling. Unless you can save the user’s position after they return to the page from clicking something, don’t do this. The user will have to scroll all the way from the top, wasting the user’s time and wasting your bandwidth even more.

Creating floating divs that pop up when you hover over text. I’m trying to read here.

Designing a website to be mobile-first without appropriately scaling up. This is just as bad as making a non-responsive website.

Needlessly using custom scrollbar solutions. These tend to break a lot and suddenly snap me back to the top of the page, or stop scrolling altogether. They also don’t scroll the way the user expects.

Using Hashbangs for AJAX crawling. That is so 2010. There are better ways to do this now.

Making black and white, animated on hover, circular cutouts for your About Us photos. Good lord, this is overplayed.

Outsourcing your blog to Tumblr. This is tacky. And what’s the point? Are you trying to anger the Google Gods? Or has Rails backed you into a corner with bad WordPress knockoffs?

Using slow CDNs. It sorta defeats the purpose.

Requiring users to use an app or sign in with Facebook. I leave every time, no exceptions.

Populating the meta keywords. No search engine since the 90s uses these. All you’re doing is giving the competition a glance into your marketing strategy.

Skeumorphism. No more cloth and wood backgrounds.

Java and Flash. The world really needs to move on now.

Leave a reply

Moon Boogie

By Chris Bartek

My latest game involves driving a jumping pink jalopy around on the moon, whilst shooting heart-shaped bullets at aliens. Believe it or not, no LSD was involved in the making of this app.

Moon Patrol is one of my all-time favorite games (I even have the standup arcade game), so it was only a matter of time before I wrote my own version. It follows the same formula, but I changed a few things here and there. I actually wrote a Moon Patrol clone about a decade ago, but the source code got lost in a drive crash… this one is better anyway, haha.

screen568x568

Get Moon Boogie for Android
Get Moon Boogie for iOS

You’ll notice the iOS version costs 99 cents, while the Android version is free. The reason for this is the Android version is way easier to port than the iOS version, and I don’t have to pay $99 a year for a developer license like I do with Apple. Also, what I’ve noticed is Android users expect everything to be free (like Windows and Linux software), while iOS users are fine with paying a buck or two (like MacOS software). So, lots of reasons.

The holes were the hardest thing to implement. The game is extremely difficult, even for me, the guy who made the game. I spent probably 3 days trying to track down a weird Android bug, but I spent even longer cursing at Xcode over a file path bug. One final note: Disco Nick is hidden in the game, as usual.

Enjoy.

Leave a reply

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

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

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