You can touch, but you better not hover

This post can perhaps also be titled ‘yet another tale of  adapting to devices that can’t yet hover’, or perhaps ‘philosophical applications of CSS, media queries, and developing for mobile devices’…

Turns out responsive design continues to be a skill I’m working on developing.

Constructing alternate layouts based on screen size is mostly progressing well.

The hardest challenge is adapting my mind to changes in UI controls.

Mobile is most challenging for me with respect to touch vs. (click + hover).

By contrast, I relish novel controls, for instance, the use of shaking in the Wake n Shake alarm clock or the Paper or Plastic icebreaker.

For instance, a soon-to-be-released  project looked sweet on machines whose browsers support hover. Clunky desktops. with mice. & notebooks. & most devices that support CSS transitions. That is, mostly iOS anything.

Not so much mobile. Especially Android. & IE. We mostly fixed that.

The redesign shrunk graphics & added text cues for hover-free devices.

Which prompted me thinking about our life having  a hover interface.

Which is one aspect of what augmented reality (AR) should provide us.

Point your camera, phone, eye, or glasses at something. Get context.

Like the HUDs in Cory Doctorow’s Down and Out in the Magic Kingdom.

Which immediately prompts all sorts of questions.

For instance, will we start designing objects to be friendly to AR devices?

Assuming so, will folks without AR devices have difficulty using those objects?

Could augmented reality be the technology that gets rid of QR codes? Forever?

The striking thought is that the devices providing us a hover-like experience with objects in the real-world, those same devices lack hover controls.

Which prompted me to dream of a mobile device case, that say by reading the position of my fingers, would provide hover controls on mobile platforms.

Which made me wonder if the awesome Canopy case had a hover mode that would tell the OS the equivalent of a mouse is linked to the phone.

Or perhaps mobile  browsers could interpret a short click as a hover.

& interpret a double click, or a long click, is well, just a click.

Kinda like a virtual mouse. on your phone. or tablet.

& mobile browsers could offer that contextual help we’ve missed sans hover.

For now, I’ll work on getting better at developing for touch-only platforms.

Upgrade and list your Rails apps versions – locally or on Heroku

Some  constructive outcomes of latest Ruby on Rails vulnerability…

Two or more guides to upgrading Rails apps — locally &/or on Heroku.

Two or more scripts to list Rails versions on Heroku — in Linux & Windows.

& learned lots more about developing  on Rails & deploying on Heroku :).

Life is an infinite scroll – or is it?

Infinite scroll is that continuous scrolling on blogs, social, & other content-centric sites.

The somewhat maligned marker of an infinitely scrolling site is the ’#!’ (hashbang) &/or ’#’ hash signs in the site’s URL.

One of the biggest issues with most infinite scrolling sites is that they don’t generate a bookmark for your scroll position.

So say you’re doing a search on, I dunno, Twitter. For itself.

It’s impossible to scroll those tweets and send a shortcut to that position.

Or a Facebook timeline position. Or Pinterest page. Or many, many other sites.

Similarly, time’s ability to reduce the complexity of life to one serialized dimension generates humanity’s infinite scroll.

So from the perspective of time, life is simply an infinite scroll in which we encounter new experiences all the way.

However, we encounter the same challenge in life as we do with Facebook or other infinitely scrolling sites.

For instance, life is more than an infinite scroll, and we’d very often like to bookmark certain life events.

Very often, we also go back to places we’ve been before and in some way cause time to loop back on itself.

Or our relationships whose webs of experiences interleave with our life activities and transcend time.

Or we use communication devices that implicitly transcend, or time travel, the distance between us.

At other times, we may make a choice that [dramatically] changes our trajectory if we were to look forward in time.

Thus, we have multiple forks in how life could go (and sometimes we find ourselves back at the same choice – again – & again.

Yep, life’s a web of adjacent possibles & plausible futures – that is to say, we coulda, shoulda, woulda.

Of course, different people use different filters to read our respective scrolls and form their perceptions of us.

Thus, our mere existence is currently finite while our life’s memories &/or our life’s effects may be infinite.

Where the living of life is something very different than simply endlessly clicking that browser scroll bar.

So get out there – live.

P.S. Infinite scrolling is also an issue when searching the deep web. Or recording the web of humanity for posterity.

P.P.S. This post waa partially inspired by Logitech’s M500 infinite scroll mouse
(#M-U0007) & this Twitter thread.

Human APIs – Feeds of the People, By the People, For the People

Everywhere, we ingest, process, and generate data.

Facebook. Twitter. LinkedIn. Blogs. Healthcare. Sports.

Much of that data is hyper-local and hyper-personal

Some folks experiment with such data vis-à-vis quantified self.

Other folks create central in & out data paths for their lives.

Google calls its Chrome browser address bar the omnibox.

Others folks collect any & all messages in a global inbox.

Which includes emailed social, calendar, & task updates.

More recently, we’ve seen a variety of persona managers.

About.me was perhaps the best among many for a while.

Now we have RebelMouse. & FriendFeed still lives on.

We use Flickr. Delicious. Evernote. & love Pinterest.

We share calendars. documents. files.

Used to share our favorite reads.

Now we share our homes. & cars.

& more in the sharing economy.

We give lots of data away non-digitally.

Over the phone to the insurance company.

In person to our doctor(s). dentist(s). therapist(s).

At schools for administrative and testing purposes.

So most of life is about the giving & getting of data.

Often in the form of implicit or explicit negotiations.

We ‘dance with the machines’ so they can help out.

Because we the people generate torrents of data.

All of these technologies point to creating a human API.

We’d require a digital ‘phone number for life’ to pull this off.

Along with privacy protocols so we control who sees what.

So instead of sending calendar invite we’d post API requests.

To us it would be the same. To machines it would be different.

& perhaps we could ‘dance’ better with the machines.

A human API would be essential to leverage mind-machine interfaces.

We could also more easily share data with doctors, lawyers, & teachers.

Or cooks, bakers, & candlestick makers. annoying neighbors. dates & mates.

Bottom line – we generate data. We store data very efficiently.

A ‘human API’ uses our data to create functional digital feeds.

Perhaps so we move beyond traditional communications.

Such as RSS. or iCal. or KML. or text. or chat. or email.

P.S., P.P.S., …

Yes, human APIs are merely a conjectured sci-fi-like technology.

Questions abound with respect to how implement such technology.

As do ethical questions on getting data in and out of our digital lives.

A shared calendar is an existing technology that hints of such things.

Late-night just-might-work guide to upgrade Ruby on Rails server during great Rails vulnerability of 2013

• stop – your Ruby on Rails (RoR) server
• edit  – appropriate line in gem file to read [one of]:
• gem ‘rails’, ’3.2.11′
• gem ‘rails’, ’3.1.10′
• gem ‘rails’, ’3.0.19′
• gem ‘rails’, ’2.3.15′
• run – gem update
• run – bundle update
• run - bundle install
• test – rspec # or test-driven dev’t framework of choice
• launch – rails s
• test – # interact with Rails server & explore if all is well
• run – git add .
• run – git commit -a -m “upgrade Rails server to ver. [x.y.z]“
• run - git push # to github or rcs of choice
• run - git push heroku # or to deployment server of choice

What may prompt you to seek this info around time it was written…

• Upgrading your Rails server(s) due to the SQL injection vulnerabilities, XML/YAML issues in ActionPack, Query Risk in Active Record
•  Unable to resolve dependencies: rails requires activesupport, actionionpack, activerecord, activemodel, actionmailer, activeresource
• AKA, the great Rails Security Hacks of 2013

P.S. Above sequence worked for upgrading our Rails projects. YMMV.