Category Archives: Development

SineBob.js: A Simple jQuery Plugin for Creating Easy Sine/Cosine Effects

By Chris Bartek

Ever notice that, even with jQuery’s Easing plugin and CSS3 transforms, it’s not really easy to make sine effects in your frontend projects? Being a game designer, I’m a sucker for sine, so this has been bothering me for awhile. Sooo… I finally decided to do something about it. This is an extremely simple jQuery plugin that allows you to add bobbing effects (horizontal or vertical), sine fades, sine scaling, sine rotating, and rotoscaling. Example usage is as follows:

Default vertical bobbing effect:
$("div").sinebob();

More options:
$("div").sinebob({direction:”left”,offset:60,length:120,interval:10});

Alternate bobbing effect (a simpler implementation with better timing control but less accuracy):
$("div").sinebob({mode:”simple”,ticks:3});

Sine Fading:
$("div").sinebob({mode:”fade”});

Scaling:
$("div").sinebob({mode:"scale",offset:10,length:1});

Rotation:
$("div").sinebob({mode:"rotate",offset:0,length:10});

Rotoscaling (both rotation and scale):
$("div").sinebob({mode:"rotoscale",offset:2,length:10,s_offset:10, s_length:2});

NEW! Text sinewave scroller (beta):
$("div").sinebob({mode:"text",length:10,increment:0.1,speed:15});

I threw this together in a day, and it is my first attempt at a jQuery plugin, so go easy on me.

Downloads (COMING SOON):
jQuery.SineBob.js v1.1
jQuery.SineBob.js v1.1 (minified)

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

Everybody’s Talkin’ ’bout the New Sound

By Chris Bartek

Not too long ago I had the displeasure of using Smarty in a PHP project for a major client. You’re probably wondering what the heck anyone would be using Smarty for in 2012… well, lots of turnkey systems (shopping carts, CMS, etc.) built from 2007-2010 use all sorts of templating engines, but Smarty, at the time, was definitely the most popular. These days, I guess PHP developers have wised up to what I had been saying for years, since you don’t really see these things being used anymore. Old-school templating engines had many obvious problems that nobody really thought of, while they were busy worshipping the concept of model-view separation. Don’t get me wrong, there’s nothing inherently wrong with this line of thinking, but… why did this seem to always necessitate the creation of an entirely new programming language? Did the Smarty people forget that PHP itself is already an amazing text processing language, and doesn’t really need an additional templating language written on top of it? To be fair, there are some nice templating engines out these days that use PHP itself as a templating engine, but honestly with good development practices, you can adequately MVC your way through a project without the need for a templating engine. If it scares your designers, then hire new ones. So anyway, the team got together and we basically all said, “is it just me, or is Smarty, well, stupid?” Unfortunately, we were stuck with it, so it didn’t matter that the development team loathed it.

I believe that templating system fiasco of yesteryear serves to prove an important point: the web development fads of today may or may not be the practice of tomorrow. It’s incredibly important that you don’t unnecessarily tie up thousands or millions into a project because it “has to be done in Node.js-SproutCore-Backbone-ExtJS-Coffeescript-SASS-HAML-960gs-Bootstrap-NoSQL”, or whatever bleeding edge technology stack of the week. It might be the hipster CTO thing to do, but keep in mind: some of these technologies may be keepers, but half of these technologies will be long forgotten in 3 years, and one or two of these will make your new programmers laugh, then hard-time you until you pay them to rewrite it in something more sensible. There’s a reason Java, .NET, and PHP continue to thrive, while stuff like Python and Rails seem to have peaked last year could be going the way of Perl and Tcl/Tk. They’re proven scalable, they have support of millions of developers, they have robust libraries already written basically everything, and they are used by the largest sites on the web. They may all be sugarless, downright ugly languages, but heck if they don’t get the job done everytime. I’m not saying all new technology is bad, obviously. Lots of amazing stuff has been popping up lately, but it doesn’t mean I’m going to rush out and use some unproven technology on a Fortune 500 company’s project, though I might experiment in certain places. There’s doing the cool thing, and there’s doing the smart thing. And yeah, I know it’s scary to use the “old way” on new websites sometimes, but I’ve certainly seen my share of situations where the old way was apparently done that way for a reason. Hopefully this doesn’t make me sound like a cranky old person afraid of change, because that’s not at all what I’m trying to convey, heh.

Leave a reply

The Future of Software Development

By Chris Bartek

I have a dream. A dream that one day, we will remove the shackles of syntax. We will stop living in the punchcard era of programming. Object-oriented will really mean visual on-screen manifestations, not junk compartmentalized in curly braces. We will stop putting the security of our computers at risk by programming everything in low-level languages. We will stop trying to abstract low-level and high-level languages by creating yet more complicated languages. We will stop using those scripting languages that function like they were created by aliens. We will give up on static typed variables, pointers, and other memory management concepts unnecessary in the 21st century. We will end the possibility of buffer overflows. We will stop the compiler errors. We will end the garbage strike. We will revolt against the Hungarians. We will stop using camels, and instead use spaces. We won’t have to memorize or rely on autocomplete. We will put logic together visually, instead of just typing code. We will truly collaborate in realtime, instead of merging and versioning. We will develop on web browsers, in the cloud. We will develop easily on a touchscreen; the keyboard won’t hold us back. We will stop writing the same code over and over again, and instead make others’ libraries easy to use and share. We will separate programming languages from software development. We will stop worrying about MVC and instead ask why the separation isn’t natural. We will bestow the power of development to frontend designers who are worthy. We will stop worrying about which language is ugly or pretty, and instead worry about why we even need languages. We will stop making programming more difficult than it needs to be. We will stop over-engineering software and go back to the KISS rule, like designers have already figured out. We will stop celebrating “clever” solutions that no other programmer understands. We will make code read more like a flowchart, and less like ASCII vomit. We will stop creating bugs and memory leaks. We will make software impossible to freeze and crash. We will modularize visually. We will create development environments so abstracted from code, it will make Python look like Assembly. We will stop creating hundreds of languages that keep failing to make our jobs easier. We will finally merge the desktop and web. We will make programming so accessible, anybody can do it. We will stop working in cubicles and instead work from the cloud. We will merge design and development. We will make programming an art again. We will make programming cool again, and not just for analytical, lispy grumps with Aspergers. We will end the seemingly endless best practices arguments. We will abolish tabs, semicolons, and braces. By the end of the decade, we need to make this happen. We must be the last developers that ever have to suffer under 1950s programming paradigms. We will go free. We MUST go free.

Flame on, lispy grumps. 🙂

Leave a reply