Noscope is a bi-weekly journal serving up snacksized portions of pointless stuff since 2001.
I also do freelance design and usability via dejligt.com

Quick Thoughts On Google In Advertisement

    13:09 on February 08th, 2010 ,

Just last night, Google advertised their core search business on the Superbowl. Prior to this they’ve been advertising the Google Chrome browser. All this is radically different from how Google used to do things, which was to not advertise at all.

Here are a two of the ads, and some quick thoughts on them.

Parisian Love:

The Flash plugin is required to view this object.

Chrome Features:

The Flash plugin is required to view this object.

So what does this mean? Here are thoughts:

  • Google has got a bunch of disposable income
  • Googles move into other businesses than search means they have to advertise
  • Specifically Google Chrome is a “must-succeed” product of Google, core to their future strategies
  • Google is the new Coca Cola, ubiquitous but in constant need of pointing out their existance so as to not be forgotten
  • Marissa Meyer has gotten really in to harp music

Buy my art

Chronicle Of Awesome: Speculation The Grand Theory Of Lost

    14:48 on February 01st, 2010 , , , ,

Beware of spoilers!

LOST.png

It seems like just a few weeks ago; I watched the season 5 finale of Lost. It was only after the final LOST logo came on to the screen that the reality of a 9 month wait started to sink in. So, impatient as I was, I decided to speculate my way to a series conclusion. Because Lost is the best thing to happen to television since color. Lost is why cave-men painted shows on walls.

Now I’ve had 9 months to speculate on these mysteries, and for the very same reason, this post will be massively spoilerful (unless I’m completely off the mark and even then). Do not read this post unless you have seen every available episode of Lost first. Otherwise, you’ll be ruining a great experience for yourself.

Warning!  Don’t ruin this for yourself.

Still here? Okay, I trust you have, in fact, seen Lost. So read on.

Continue reading… »

7 Comments

Why The iPad Doesn’t Have Multi-Tasking

    12:39 on January 30th, 2010 , , , , , ,

One of the things discussed about the new Apple tablet, other than its lack of Flash, is its apparent lack of multi-tasking. Multi-tasking, of course, being the ability to listen to music or radio while playing Flight Control. I’d like to talk about that, because I’m pretty sure I know why there’s no multi-tasking, and if you’ll let me attempt prescience for a moment, I’m going to let you in on the secret.

Multi-tasking doesn’t work well enough yet. That is also to say that when it does, Apple will feed a system update which adds this feature; to the pad and phone alike. It’ll be just like when you all got copy and paste.

I’m an Android fellow. I cannot accept the closed platform that is the Apple ecosystem. The fact that I’d have to open iTunes to get stuff on to my phone instead of being completely unrestricted1, is something I couldn’t ever imagine settling for. Additionally, I am enjoying multi-tasking on my Android phone today; I’m listening to podcasts via Google Listen while browsing Wikipedia, and it’s a bliss I’m sure iPhone OS users will appreciate soon enough.

Even so, the Android implementation of multi-tasking is an example of why Apple hasn’t done it yet. Gruber was boggled by the need for a task killer on the platform, and frankly — so am I. Which is key to this issue. A single-tasking platform closes every app when a new app is invoked. The robo-logistics are simple: “Home” means “Save & Close”. Because this is simple, it works. Transparently, easily, and without the need to peek inside the system to see what’s running and what shouldn’t be.

Both Android and iPhone OS are pioneering new ways to interact with computers (which incidentally is why I now prefer these OSes on principle, over Windows, Linux and OSX). The new trend is to tuck away the filesystem; to whittle down all the nerdy stuff. To make it feel obsolete and unnecessary. You don’t drop your music into a folder, you drop it onto your phone and then sort it using meta information such as artist, year, album and so on. You also no longer window manage. You don’t open an app, you enter Google Listen. You don’t close an app, you press “Home”. If you were playing a podcast, it keeps playing even as you enter the browser to explore Wikipedia. If you weren’t playing a podcast, the system cleans up any stray processes for you, so the system doesn’t spend memory that isn’t needed. It’s all very elegant, and once you get used to it, closing apps feels very 1990.

Except it’s not as elegant as it sounds. Because apps themselves decide when they’re done using your battery and not all apps are good citizens. Sometimes you’ll click “home” with the intent of not going back to your game of Robo Defence. But Robo Defence isn’t sure what you want, so it’s just paused your game. Which means goodbye battery. Which means you need a task killer, whose sole raison d’etre is giving you a neat list of which apps are running in the background and the ability to forcefully close them. 

I’m sure Android will get there. Development is moving at a blinding pace; in fact things may already be better in version 2.1. In the meantime, I’ll be loving my Google Listen background process. Even if it means I need a task killer. Once Android grows up, I’m saying a fond goodbye to my task killer, and I will never look back. But I’m not a normal user. I’m not one to be impressed by Apples “only launch when perfect” ideology, I much prefer Googles “launch early, iterate often” approach. I’m also smart enough to understand why Apple postpones multi-tasking until they get it right. Which is when you’ll get multi-tasking on your iPhones and iPads.

[Update]: Michael points out in the comments, that the iPhone has been able to play podcasts in the background since launch. My bad example. Please appropriate “Google Listen” with “Pandora” and my example will make sense again.

  1. Incidentally, I currently use an Android file explorer app to connect to my NAS and copy things from over the air.   

11 Comments

Games On The iPad: Here’s A Thought

    10:43 on January 28th, 2010 ,

Yesterday, Apple revealed a much hyped tablet PC, which apparently runs all current iPhone apps right out of the box. With a pixel doubler, if you want it, even.

Unimpressive as that may sound, this holds the potential to alleviate pixel shaders to great effect. Think 3D iPad games which run in hi-res, full detail on the pad, but scale down gracefully to the iPhone by simply turning down the amount of 3D detail. You know, for when you want to take Christmas Whack-A-Mole with you to the bus. I can see it happening.

Android: On Context Buttons

    10:38 on January 20th, 2010 , , , ,

Capacitative.jpg

David Barnard complains about the capacitative buttons below the Nexus One screen. As I have done in my Motorola Milestone review. But it gets both more interesting and, unfortunately, worse, in the story of these buttons.

There are four buttons1:

  • Back
  • Context menu
  • Home
  • Search

While programmable, the back button mostly works as you’d expect. When in the browser, “back” goes back in history as any browser worth its salt should. When you’ve just started an app, “back” goes to your homescreen. If you’re in an app, browsing menus, back goes to the parent menu. If you’re playing “Solitaire”, the back button has been programmed to undo the last move. This is a very useful button, as useful on an Android handset as in a browser where “back” takes up the prime real estate.

The context menu is an intriguing design. It’s most comparable to what happens when you right-click on a PC: same as if you right-click on your desktop, if you context-press on your homescreen, you get to change the wallpaper. If you’re in an app, context-press invokes the options menu. In both cases, when you press the button, a menu pops out with a context menu: “Wallpaper”, “Share Image”, “Options” and so on. I’ll get to the usefulness of this in a second.

The home button works as the iPhone home button does. It takes you to your homescreen. More than that, if you press and hold the home button, an Alt-Tab like menu showing recent apps is invoked, which is useful if not completely necessary for multitasking. Similarly, the search button when single pressed opens a Google search, whereas a long-press invokes “search by voice”2.

Useful On A Whiteboard

So, while the first three of these buttons are indeed useful (and I do honest to goodness use them all the time), I would argue that they shouldn’t exist. As compared to David Barnards piece, not for one but for two reasons:

  1. They encourage lazy app design
  2. Like Barnard says: you’ll sometimes hit these buttons when you don’t want to

To elaborate on #1, this is mostly related to the “back” and “context menu” buttons, which you’ll have to deal with if you’re an Android app writer. Obviously, the iPhone does well without these buttons. The back button on an iPhone app is usually an arrow-elongated pill button in the upper left corner (like a browser), and option menus are also usually available from aptly titled buttons. So essentially there’s no reason why an Android app couldn’t work like this. The whole idea of adding these buttons, however, is to save space. On a tiny screen, I hear the initial Android handset designers argue, you shouldn’t have to make space for back and options buttons. Which in theory may be valid, but in actual practice isn’t a problem at all since these screens scroll. The net result is that at least the back and context menu buttons become mystery meat navigation: you won’t know what happens until you press. Potentially disruptive.

Lastly, the fact that these buttons are usually capacitative buttons (as opposed to tactile, pushable buttons) that are placed in immediate extension of the screen, sharing the same glass, means you’ll accidentally hit it once in a while; whether it be in a browser and you accidentally scroll down on the home button, or as in Barnards example, when you press space on the keyboard. Gruber argues, and this is apt, that if you could compare a touch screen to a computer screen, the capacitative buttons on the Nexus One are right in the prime real estate area: the screen edges. Which means they’re easy to hit, even when you don’t want to.

The worst problem with these buttons is that now they exist, both Android and Android apps rely on them. An Android handset without these buttons would be less than useless. That is, unless Google decides to do what’s right as soon as possible and deprecate these buttons, thereby pushing developers to design UI that works without them.

  1. On some systems, there are only three, the Search button being omitted.   
  2. Which doesn’t work nearly as well as you want it to, but that’s another story.   

2 Comments

A Few Notes On Google Android And “Multitouch”

    21:10 on January 19th, 2010 , ,

The word “multitouch” is thrown around a lot these days. Mostly by people who should know better.

Multitouch means you can touch the screen with multiple fingers, and the system will register this as, yes, multiple fingers. Google Android does support this, has supported this for a while, and most Android phones have the hardware that supports it as well. So when you read the sentence, “Android doesn’t have multitouch”, what you should be reading is, “Android doesn’t support pinch-to-zoom in the browser and image viewer on US handsets”. Now that’s settled.

Listening to Windows Weekly #139, Leo mentions he’s “heard” that the reason US phones don’t have pinch-to-zoom is that Apple has a patent on this in the US (not Europe), and that Apple knows this patent won’t hold in a court. So Apple, former good friends of Google, has asked Google kindly to not try this patent and simply put off the pinch-to-zoom for a while.

Which, if true, is a delicious piece of info, worth blogging and opening comments on. Personally, I can see why Google wants to stay friends with Apple for as long as possible, but perhaps it’s time Google showed Apple the brass ones they flashed China the other day?

4 Comments

Vanilla CSS Un-Reset With New Clearfix

    13:59 on January 18th, 2010

My Vanilla CSS Un-Reset has been updated to 0.9.8 and now features a new interesting clearfix.

clearfix.png

I suppose that sentence deserves a little backstory. First of all, a “clearfix” is a solution to an issue inherent in using CSS to layout webpages. If you have a containing div box that contains two floating div boxes, the containing div box will “collapse” to a thin line instead of encompass its contents. The clearfix is a CSS class you apply to the containing box, in order to have the box not collapse.

A CSS Un-Reset is a framework that helps you build websites really quickly. In day to day webdesign, a CSS Reset such as the Yahoo CSS Reset helps you level the playing field between all the different browsers and their default styles. CSS resets are, however, (and by definition), very barebones. So Vanilla helps you rebuild.

Now that the new IE8 friendly CSS clearfix has been added, why not jump in?

Sliding Doors In Wordpress

    11:34 on January 14th, 2010 ,

A default Wordpress page menu is built like this:

<?php
wp_page_menu(array('depth'=>'0', 'sort_column'=>'menu_order')); 
?>

– which outputs a plain menu, <li><a href=" ... ">Menu Item</a></li> and so on.

If you want to use the sliding doors CSS technique, however, you need more markup. So do this:

<?php
echo preg_replace('@\<li([^>]*)>\<a([^>]*)>(.*?)\<\/a>@i', '<li$1><a$2><span>$3</span></a>', wp_page_menu(array('echo'=>false,'depth'=>'0', 'sort_column'=>'menu_order')) );
?>

– which’ll output this a more CSS friendly markup: <li><a href=" ... "><span>Menu Item</span></a></li>.

A Temporary Way To Deal With Windows’ Awful @font-face Rendering

    11:15 , ,

Windows smooths fonts, oh yes. In several different ways. Unfortunately, none of these font smoothing mechanisms properly round the edges of CSS fonts embedded using @font-face. This is most visible when using CSS fonts for body text, but it’s bad enough. So do we stop using CSS fonts for body text? No, we show CSS fonts on OSX which renders them properly. Here’s a code snippet care of Chris J. Davis, which will replace your body text font with Arial when on Windows:

<?php // use Arial if on Windows 
if (!preg_match('%Mac OS X%', $_SERVER['HTTP_USER_AGENT'])) {
?>
<style type="text/css">
<!--
/* Dear Microsoft, please fix CSS @font-face rendering on Windows */
body { font-family:Arial, Helvetica, sans-serif !important; }
-->
</style>
<?php } ?>

Gordon: Open Source Flash Player In JavaScript

    21:48 on January 13th, 2010 ,

Gordon – An open source Flash runtime written in pure JavaScript with SVG

Gordon is written by @tobeytaylor. Because it’s JavaScript and SVG, it even runs on the iPhone. Support is limited, currently, but development seems to be picking up. Best part: it doesn’t crash.