Category: Web Design

Vestatrek: Now That’s What I Call a Web App!

NASA has just released a new Web app called Vestatrek that is a shining example of what Web-based applications can do in the real world.

Vestatrek is a VR kind of site that is also a space explorer and a laboratory rolled into one highly responsive and engaging program. Using it, you can explore the surface of the asteroid Vesta, the second largest body in the asteroid belt. The spacecraft Dawn spent almost a year investigating Vesta on its way to its present location orbiting Ceres, another large microplanet / asteroid.

This app is amazing and great fun. I spent over an hour playing with it this afternoon. If offers 2d and 3d views of Vesta’s surface, you can navigate around, zoom in and out, overlay the mapping with displays of color (revealing relative depth) and hydrogen levels, measure the distance between things in terms of meters, miles, or Golden Gate Bridges or even school buses! It packs an enormous amount of functionality and data into a Web browser-based app that responds to the slightest touch of the screen or a pointer or trackpad.

Not only is it fascinating as an app, it’s a great counter to the argument that Web apps aren’t and can’t be performant, that they don’t scale, or that they aren’t really cross-browser and cross-platform.



The Latest in Web Design Aesthetics Drives Me Crazy

I guess I’m old.

I’ve finally reached the point where change — something I have sought out and embraced all of the nearly 70 years of my life that I can recall — is no longer always welcome.

The most recent example: the latest trend in Web site design. Large, graphic-intensive opening pages or screens with huge, screaming headlines and not a shred of usable content in sight. Here’s an example, but I’m not picking on this particular article. It’s just the straw that broke the camel’s back this morning. This is an article in which I am truly interested.

But when I get to the page where the article is published, I’m faced with an entire screen that has all of nine relevant words below what I guess is supposed to act as a menubar for the site. That’s it.

OK, so giant headlines are being seen as cool. The artists who design the Web are getting to move beyond the confines of largely text-based layouts. I can deal with that;I’d rather not, but I can.

So I scroll down. (And therein lies the real point here; if you publish something for me to consume, why do you let your design aesthetic get in the way of my being able to consume it with minimal effort?)

The next full screen I can see has less than 50 words in a sub-head in fairly large type, with a ton of white space around and within it. Then it has the obligatory credit lines. Then the actual article begins and shows me…less than 70 actual words of content. In part this is because of a drop-cap “W” that occupies a huge space in the middle of the screen, drawing my eye away from the freaking article I freaking came here to freaking read!!!!

It seems to me that virtually every design decision made here was made by artists for artists, reader/consumer be damned. I’ve already had to scroll twice and I’m not reading the meat of the article yet. What ever happened to “form follows function”? This is not functional, people!


WordPress 4.0 Should Have Been 3.10

Some time in the next few days, if all goes according to plan (not always the case with software), WordPress 4.0 will burst forth onto the Web design scene causing nary a whimper in the fabric of spacetime in the process.

wplogoYou’d think that an upgrade to a major rev level like 4.0 would mean huge changes to the functionality and/or core engine of a product used as widely as WordPress (probably approach 100 million sites on the Web by now).You’d be wrong.

This version is such a tiny incremental upgrade it is undeserving of being called 4.0; it would be far better labeled 3.10. As far as I can tell, not one significant change is taking place that WP users are likely to care much about. Here’s a page at that allegedly lists the most important end-user features and enhancements. I think you’ll agree there’s not much there to get your heart pumping. Here‘s another attempt to put some lipstick on the pig. I just don’t see it. Some nice improvements to be sure but enough to call it a major new rev? Nope.

One of my biggest objections to WordPress (which I use…a lot!) has been the too-frequent upgrade path. That’s one reason all the ballyooing about this one has me scratching my head.


Check Out These HTML Tags Just for Picky Formatters and Writers

I haven’t seen a lot of chatter in the HTML5 world about some new tags that are designed for people who are a bit more meticulous than most about how their text is formatted on their Web pages. I found this collection of six tags interesting and not a little weird in some ways. (Note that only two of these — mark and wbr — are new in HTML5. The “s” tag has been undeprecated (is there such a word) and given a new job. The others existed in HTML4 but I never saw them used so I threw them in here anyway.

(Depending on your browser’s support, the examples shown with each tag may or may not work. The links to the W3School site where there is an editor that allows you to try these yourself might be more useful in that case.)

Note, too, that you can use CSS as usual to format the output of these tags any way you want.

  • del

    strikes through (deletes) the text between the tags, as in: I know I said blue, but I meant red!

  • ins

    inserts the text between the tags, underlining it to depict its insertion. Here’s the above sentence, with “red” enclosed in ins tags: I know I said blue, but I meant red!

  • mark

    highlights the text, by default in yellow (but of course you can use CSS to change this). Example: I want to draw attention to the previous two words.

  • q

    instructs the output be placed between quotation marks, as in: I was sure you said, Leave me alone! Perhaps I was wrong?

  • s

    instructs the output to be struck through, or lined out. The third and fourth words of this sentence are lined out.

  • wbr

    is a weird one. It is useful when you have a really long single word as often crops up when you are writing programming language documentation. By inserting the empty wbr tag at appropriate points in the string, you give the browser permission to break the string if necessary when wrapping words. The next line should help you understand this.


Choosing Between JavaScript and Python and Ending Up With CoffeeScript

I’ve just about completely given up my Web design & development business as a way of making a living these days. I’m focusing instead on being a content creator for clients who can benefit from my ability to research and absorb information on a broad variety of topics quickly and to equally quickly render my knowledge into cogent words. These can then become blog posts, press releases, long guest articles or for that matter eBooks.

But that doesn’t mean I’m giving up my long and deep interest in building stuff for the Web. I’ve just decided that I no longer want to do so under deadline and for clients who have to depend on me to finish work on schedule and under budget. There are many reasons for this decision and they’re beyond the scope of this post. Suffice it to say that I’m now looking at Web development more as a hobbyist.

That has been incredibly freeing.

Since what I want to build for myself — and for the occasional friend or non-profit who is willing to wait for the result — are Web applications rather than standard Web sites, I want to choose a language in which to work that I can have fun writing, that doesn’t require me to spend too many hours poring over arcane (i.e., C-like) syntax, and in which I can be reasonably productive on both the client and the server side of the Web.

I began my new study of this subject open to any language. I surveyed the field, narrowed it to a few, spent a few hours examining each and reading positive and negative reviews and reading sample code. Ultimately, I narrowed my choice of language to three: Python, Smalltalk and JavaScript.

The first big problem I ran into is that there really isn’t a very good way to handle the client side in Python. There are kludges and vague attempts at translations, but none of them is either stable, well-supported or very clean in terms of the way they handle the output to be stored in the client. In essence, I can substitute Python for PHP with ease, but I’m still stuck with a four-language solution (HTML/CSS/JS/Python).

Smalltalk suffers from nearly the opposite problem: deployment on widely available Web servers is all but impossible. There are a couple of Web servers written in and for Smalltalk but they are little-used, and require me to become the maintainer of a server. That’s not my interest.

Still, I clearly want (need?) a single-language solution for client and server-side programming. Clearly the only real widely used language that meets that requirement is JavaScript. But the syntax. Ugh.

CoffeeScript LogoBut then I remembered encountering CoffeeScript. I took a quick look, read and worked through a quick tutorial, and then spent a couple of hours investigating its use in Web development. I am impressed with the clean syntax of the “language” (it seems to me to be not quite a language but a sort of meta-language).

So my new approach is to master CoffeeScript and incorporate JQueryUI on the client side and (presumably) backbone.js on the server (though those choices are still wet paint) to support the creation of Web apps. CS compares fairly favorably to  Python from a clean-syntax perspective, uses white-space formatting as its structuring mechanism (which I really like for a number of reasons) and has a pretty extensive collection of libraries, recipes and plugin/add-on tools.

A Little Book On CoffeeScript CoverI’ll keep you posted on my CoffeeScript journey. It may turn out to be another blind alley but I’m going to give it a fair try. My first step is to pick a good second book (beyond the Little Book on CoffeeScript with which I’ve already started to learn the basics.)



Firefox 3-10x Faster Than Chrome on WordPress Sites?

I’ve been noticing lately that when I work on WordPress sites in Firefox, everything moves faster: 3-10 times faster by my own rough clock count. This doesn’t make any sense to me. In general, Chrome is somewhat faster than Firefox when I’m simply browsing the Web and even when I’m using Google Apps. But when I edit WP sites, for some reason, Firefox blows Chrome’s doors off.

I’m running the latest releases of both browsers on OS X 10.8.4. Of course WP settings are the same. I am scratching my head over why this should be the case.

Anyone have any similar or contradictory experience or any explanations or ideas?


Kill the Carousel

On LinkedIn’s WordPress Web Designers Group, we’ve been engaged in an interesting discussion about the use of carousels and sliders on home pages. There is a general, somewhat vague sense that they are not liked by many in the design world, but today one of our members, Phil Turpin, posted a definitive answer that got my attention.

Phil pointed out that as a practical matter, carousels are SEO death traps. Pointing to an article on SearchEngineLand, Phil said that he, for one, hates seeing them and never uses them for clients. Here’s what SEO expert Harrison Jones said on the SEL site is wrong with sliders and carousels:

  • violation of the one-h1-tag-per-page SEO heuristic
  • using Flash
  • shallow page content appearing well below the fold, forcing scrolling, a huge SEO no-no
  • Nobody clicks on the carousels anyway.
  • confusing objectives

This is important stuff. Unless the site is not designed to attract and convert customers, they are in fact deal killers. Any one of them. Taken together, they are deadly.

Get rid of carousels on your customers’ Web sites. Now. They are horribly counter-productive no matter how slick they might appear.