:hover is dead Jim.

The :hover pseudo-class is dead, it just hasn't fallen over yet. In fact it's not just dead, it was murdered. Killed by the touch interface.

I'm not exactly clear on when :hover was created or by whom. It was included in the May 1998 CSS2 specification and I believe Microsoft's Internet Explorer 5.5 beta in December 1999 was the first browser to implement it (but only for the "a" tag, which is still true today). I've seen reference to Microsoft having invented it and contributing it the CSS specification. It was subsequently supported in other browsers.

You've seen :hover everywhere on the web for the last decade. Initially web coders fell in love with it because it provided a pure CSS method for doing image rollover and show/hide effects that previously had required Javascript to work. Because the W3C never limited what elements could be assigned the :hover pseudo-class it meant that (aside from IE) you could make hovering over any element you chose trigger a CSS event.

In many ways you could argue the ubiquity was actually an abuse of the function, and I've seen blogs decrying it as a crutch for bad user interface design (an easy hack to selectively show content that otherwise didn't fit into the layout). On the other hand it could also enhance the user interface by providing feedback to users regarding what was "interactive" and what wasn't or providing contextual information depending on with what element a user was - or was about to - interact.

If you think about it the :hover pseudo-class is actually a pretty amazing little bit of shorthand. It tracks the pointer position when it is over the coordinates of the element to which it is applied and can perform actions based on that detection. Take something as simple as the very common image rollover on a button - with :hover it can be accomplished in one line of code that single line could create the rollover effect for EVERY button on the page. Try to accomplish the same thing with Javascript and you'd have to give unique IDs to each button, create custom functions that could be called from those buttons that defined variables for the height, width, and top+left coordinates of the button itself and then another function to track the mouse coordinates and yet another function that performed the swap-out on that button, but only if the mouse coordinates were within the same area defined for that particular button. That fact that :hover can accomplish all that in one line of code is frankly. . .beautiful.

Then along came "touch" interfaces. PalmOS, iOS, Android, WebOS - all the mobile operating systems for touchy-feely devices like the Blackberry, Droid, iPhone, iPad, iPod Touch, Galaxy Tab, etc. They don't DO hover effects. Why? Because the "hover" represents a proximity-based feedback and touch devices have no way to detect if you are "near" or "about to interact" with an element. You're either touching it or you're not.

In touch interfaces there is simply nothing similar to hovering - of if you prefer the Javascript mouse event name for it "onmouseover." Which is what we're really talking about here - are touch equivalents to mouse events:

mousedown = touchstart

mouseup = touchend

mousemove = touchmove

mouseover = ???

mouseout = ???

click = "Tap" (click actually generates a mousedown+mouseup, so tap is a touchstart shortly followed by a touchend event)

dblclick = Two quick "taps" (dblclick is rarely used, but technically you could script touch events looking for two taps in quick succession on a single element)

contextmenu = touch and hold (keeping in mind this triggers default touch callouts for things like saving images or copying text. If you wanted it to display a custom context menu you'd have to disable the default touch callout and try to detect a touch and hold event by timing how long a touchstart on an element sustains without a touchend event)

Additionally, in the "mouse centric" desktop world you only have ONE pointer. It's ALWAYS on the screen at some coordinates. In the "touch centric" world the "pointer" doesn't exist until a finger touches the screen, and in the case of multi-touch interfaces you might simultaneously have five or ten "pointers" to track on the screen!

The :active pseudo-class is the CSS way of detecting a mousedown event but it generally won't trigger an active state class change with touch interface "touch and hold" even if you've disabled the default touch callouts - you'd have to add a touch event listener to the element and trigger the style change from javascript. I've had success using the :target pseudo-class on "a" tags to get a touch interface to trigger onclick type events (for example hiding a layer), but it's clumsy.

In fact I'd say the one thing I presently do NOT like about coding for touch interfaces is how clumsy it is. You're stuck using Javascript to accomplish anything with it - even when you are using touch-specific CSS extensions, you still need scripted event listeners to make the elements touch-friendly. Ideally what we NEED is a :touch pseudo-class that does all the heavy lifting - but with no agreement in the industry on how touch interfaces work we're probably forever saddled with scripting and proprietary code and classes.

You can DISABLE various default touch behaviors via webkit CSS extensions:

-webkit-touch-callout: none; (prevents the "right-click" style options on a long press)

-webkit-tap-highlight-color:rgba(0,0,0,0); (prevents "highlight" color on touched links)

-webkit-text-size-adjust:none; (prevents automatic text resizing)

-webkit-user-select:none; (prevents elements from being selected by touch)

What does that mean for the web? It means as pages are optimized for interaction with touch interfaces all the "mouse-centric" methods will go away, relegated to obscurity. The word to the wise these days is to not only design for mobile devices, but to design for TOUCH interfaces. That means you don't use :hover or :active in your CSS anymore. That means you add support for touch events and selectively disable mouse events (because there is inconsistency between mobile devices regarding the interpretation of mouse events as touch events - a single touch can trigger a slew of mouse events all at once, which can cause unwanted results if you've coded the page to do certain things depending on each mouse event).

There simply is no touch event that is similar to hovering, so don't use it anymore. Actually the W3C was aware of this from the start as the CSS2 specification state that some input methods (it specifically mentions pen input, which is a lot like single-point touch) as not being able to support the :hover pseudo-class. If stylus input methods had become popular at the start of the 21st century we'd probably have seen :hover fade away before it even got going. But here we are decade later and touch is input method of choice. Sorry :hover, you have to die. The mouse will likely be keeping you company in your crypt soon enough.

Creating an Object VR in Google SketchUp and Kerkythea

You've seen them for product shots on online stores - nice little 360 degree views of a product as it rotates on a turntable. I've done some packaging mock-ups in Google Sketchup and have been trying to find a decent way to render them as Object VR images. It wasn't hard to find solutions for CubicVR panoramas, but finding a VR method looking inward rather than outward proved more of a challenge.

SIMPLE WALK-AROUND METHOD

1. Click the "Front" view

2. Create an Animation Scene

3. Repeat Steps 1 & 2 for the right side, back, and left side

You'll now have 4 camera positions around your object and can animate between them as if walking around your object (or as if spinning your object on a turntable).

Go to File>Export>Animation and you can tell it how many frames per second and how big to render the images. You can either export it as a Quicktime video or as individual image files (keep in mind that is one image for each frame). At a bare minimum you only need the four views, but it makes for a very choppy rotation. The preset duration is 2 seconds from one camera to another so the lowest setting of 5 fps will add 9 frames between each of the ones you've created (the 1st frame is the scene you created for a total of 10 frames for each segment).

You can then take the images into VR software - I have VRworx Toolbox - and create an Object QTVR mov file that is truly interactive, rather than just a video. The images can also be used in other programs that can make VR files. If you want to reduce file size you can simply not use all the tween animation frames - just grab one out of the middle or a couple near the middle (depending on how smooth you want the transition from one view to another). I'd recommend not going fewer than 8 views (front, left side, back, right side, and one 3/4 view between each straight on view).

The problems with this method are, while it may be easy to do, it is limited to the default views and the animation path won't export to Kerkythea correctly and even trying to use the scenes with the Walkthrough Animation dialog doesn't work right (not sure why but the camera "swims" all over the place until it gets to the next scene) so you're stuck with the low quality "cartoon" images that Google SketchUp creates.

CAMERAS ON A CIRCLE

What we need is the ability to put our camera positions on a circle and precisely control the point at which each camera is focused. The video I found below is a good start!

In the video he wants an "ant eye" view of the car, so his cameras are positioned along the floor and looking upwards to a single point. He even raises the car model and updates his scenes at the end to make it more dramatic. In my case I have smaller objects like a candy box, which make more sense if you look downward at them. I grabbed my circle and raised it slightly above the height of my model then positioned each camera looking downward to the center.

However, as I said the images look sort of like cartoons. I want nice renders! The simple method I talked about doesn't export the animation to Kerkythea properly, but this precision method thankfully does. It takes a little more work, of course. . .

PHOTO RENDERING IN KERKYTHEA

1. First, I need to modify the method outlined in the video slightly. Instead of moving my model to a new layer I need to keep it on the default layer (the one you can't delete). Why? If I don't my model wouldn't export. So I create my circle and central post on the secondary layer. Other than that I do what the video says up to the point of exporting the animation.

2. Instead of creating a Quicktime movie I go to Kerkythea Exporter > Export Model and open it up in Kerkythea. I can close SketchUp at this point.

3. In Kerkythea I go to Tools > Walkthrough Animation and it pops up a dialog box. Enter a name like "VR" in the first box.

4. In the Walkthrough Animation dialog click the "Add Node" button. In the drop-down list select the first scene.

5. Continue clicking "Add Node" and selecting the next scene in the sequence around your object.

6. Under "Duration" I enter a one. What?! Yep. You want a duration of 1 seconds for this.

7. Under "Rate" enter an 7. Click "OK"

8. Select the animation "camera" in the left pane of Kerkythea.

9. Go to the Render button, a dialog will pop up. It should already have the Walkthrough Animation name in the first box because it was selected in the left-hand pane. Decide how big and nice you want it to look and what rendering method to use. Click "OK"

10. It will open a Save dialog. Enter a file name. This will be appended with the frame numbers as each one is created. Click "SAVE" and sit back. This could take a while if you used a higher resolution setting.

Ok, to explain what I'm doing here I told it to make 8 frames (the current view + 7 frames) and run a total of 1 second (8 fps), which means I will get a sum total of just EIGHT fully rendered images. If I was rendering smaller resolution images I could enter something bigger like 16 or 24 for smoother rotation. If I was rendering these for video, though, I'd need a helluva lot more frames (if I left it at the default settings of 10 seconds @ 24 fps = 240 images).

Now I take my 8 views and import them into VR software to create an Object VR or I can put them in a web page and use a CSS Image Map to create a roll-over animation effect (as someone drags a mouse across the image it will swap out the views creating the illusion of a 3D object rotation). This way I can give viewers a nice, crisp, high quality photo render of the package design while only having to load 8 images.

End note: If you're familiar with Google SketchUp and Kerkythea you may have wondered why I didn't just export the animation path from SU to KT? Well, it appears that the Kerkythea exporter will only "see" objects on the default Layer 1 in SketchUp. So when I attempt to export my animation path it fails because, so far as the exporter is concerned, there isn't one. It doesn't matter anyway since it's so easy to recreate the animation path in Kerkythea with the Walkthrough Animation dialog. Now, if I had a really complex animation path (for example one created with the Bezier curve and Flightpath plugins) I'd probably want to move my animation path to the first layer so I could export it. But for something as simple as a circular orbit around an object why bother?

Unneeded Android Apps

Android is a phone OS. That much is clear if you own an Android Tablet. There's tons of phone-related stuff still on it. Worse yet the standby cell service is a notorious battery drainer (even if there is no cell radio present - don't ask me how that works). Here's how I got rid of it on my Haipad M701-R over ADB:

adb shell mount -o remount,rw /dev/block/mtdblock3 /system
adb shell mv /system/app/Phone.apk /system/app/Phone.OLD
adb shell mv /system/app/TelephonyProvider.apk /system/app/TelephonyProvider.OLD
adb reboot

Since my tablet came from China it has home market apps on it of no use to me. Some uninstall normally, others won't and need to be force removed. Here's how I got rid of EOE Market:

./adb remount busybox
./adb shell
rm /system/app/eoemarket.apk
cd /system/bin
sh pm uninstall com.eoeandroid.market
sync
exit
./adb reboot

Google Maps also has an issue that it won't update because the preinstalled version is locked down. A similar set of commands extricates it so I could install a newer version that will update properly:

adb remount busybox
rm /system/app/Maps.apk
cd /system/bin
sh pm uninstall com.google.android.apps.maps
sync
exit
adb reboot

A word of warning, though, that there is always a possibility you could "brick" your tablet doing this and these commands are specific to my tablet - and all worked - but that is no guarantee they will work on yours. You should list the contents of the the folders first to make sure yours doesn't have a slightly different file name and also not all Android devices use the same naming convention for the mtdblock partitions.

Lastly, I have one app that shows up in the list when I filter by "all" in Settings>Manage Applications that I don't know what it is because the name is in a foreign language: