interaction for luddites

jQuery .css() and Dynamic Background Images

I’ve just spent several hours trying to debug a nasty issue I was having with some simple jQuery. Using SharePoint 2010’s REST api and jQuery.

Setting properties using the .css() function in jQuery’s API is actually pretty easy: $(‘#element’).css(‘property’,’value’);

Should do it.

Setting the background image property is a little different, but not terribly hard either - you simply need to remember to wrap your image path in the url() function, which is a CSS construct.

$('#element').css('background-image','url(my/path/value.png)');

There’s quite a few articles online on this, so when my background images weren’t loading, I played around with this syntax for quite some time trying to get it all to work.

Well, as it turns out, my problem was something else.

My Scenario: Using SharePoint 2010’s REST Api for lists, I am pulling everything from an Image Library called “Front Page Images” hosted on my site. Then, using the .css() function, I want to set the background image of a div for each image in the library.

The big catch was that the image library’s name had spaces in it! As it works out, something in the jQuery/javascript/CSS stack is pretty picky about spaces in urls. Poking around with the div’s background image property in Firebug a bit showed me that replacing the spaces in the path with “%20” (the url escape character sequence for space) resulted in the image appearing!

The Solution in the end was to use JavaScript’s native encodeURI() function on the image path before setting the css with jQuery. Like so:

var path=encodeURI('my/path/value.png');
$('#element').css('background-image','url(' + path + ')');

Et Voila! Now I can stop pulling my hair out.

Another go at Branding

Put together another logo for my prototyping class. This wasn’t necessarily required by the class, but we had a little extra manpower on the team, so I volunteered to give this a go.

Critiques are welcome!

Favor Mob:
[Typeface is Corleone from DaFont]

Initial Design Concept

Framed for presentation

With color guide added for branding

A revised stab at it, with a gap between the running man logo and the text

Icon design for app launching

What do you think?

Birth of an Icon

Well, not an Icon, I suppose. More like a logo. Really, this is more the seedling of a brand than anything else. I’ve got a good friend who is looking to start a business selling her beautiful hand-sewn goods on Etsy. She mentioned her intents to me recently, and caught me in one of my more creative moods. I threw together a quick logo mockup for her, which included some different ideas for logo designs, as well as colors for her brand.

Anyway, I thought some of you might enjoy seeing the whimsical creative process I went through. Here’s some of my mockups.

This is the one she liked the most, by the way.

Improving text messaging with speech + type…

I can’t be the only one that does this.

Scenario: You’re busily typing away a text message on your touchscreen smartphone, and it’s not going well. Ideally, it’d be great if your phone had some inherent sense of what you wanted to say, and could guess what words you wanted to say. Most phones aren’t smart enough to be able to understand the context of the sentence you’re typing, which is a bummer - it’s also a somewhat difficult problem to solve. Too many times I’ve tried to quickly type like this

only to look down at my phone afterward to see this

That’s 2 errors, for those counting. And that sentence doesn’t come close to making sense! Now while I’m fairly sure that this happens to quite a few people, it’s likely limited to smartphone superusers — those of us who are familiar enough with our phones (or busy and ignorant enough) to type quickly without looking, at least some of the time. And before you get all up in arms, let me state for the record that I don’t condone texting while driving. Don’t do it; it’s dangerous.

While complaining about this is all well and good, I really think that mobile phone technology’s at a place where this whole experience can be made better. Until good grammar prediction comes along on mobile phones, I think that the addition of natural language speech would make texting far more accurate.

I, for one, often will mumble the message that I’m trying to send as I type in my text message. I haven’t done any research, but my guess is that I’m not the only one. I’d be more than happy to dictate to my phone while I type, if it meant for more accuracy off the bat.

What do you think? If my idea totally off the mark? Do you talk to your phone?

Post Script

I’ve come to realize that I may not have explained myself well enough. What I’m getting at here is that when communicate, we use more than one medium of communication to convey our meaning. Beyond just speeking, we gesture, and make faces (among other things) at the same time - this is especially useful when you’re speaking to someone in a situation where they may not hear you well.

Socially, we’ve gone as far as adapting our online conversational skills to help this. Putting emoticons like :), ;), and :( into an email, IM, or text adds context to your conversation, so that the person you’re talking to can understand you better.

So in the end, why can’t we use our natural multimodal communication style to better communicate with our gadgets? By typing and speaking at the same time, my phones would have a much better idea of what I’m trying to tell it to do. Our technological metaphors already allow for one or the other (IE voice-to-text or typing, which, if I’m not mistaken, you can do on Apple’s IOS, Android, and Windows Phones) - the next logical step is to combine the two.

Pass@word1 Usability 101

I should probably prefix this whole post by stating that I’m far from an expert on computer security and the like, so if something I’ve said is wrong, please do us all a favor and correct me.

So here’s something that frustrates the hell out of me - websites with unreasonable password restrictions.

I don’t think anyone with a functioning mind would argue with the idea that account security for your presence across the web is extremely important. People are continually putting more private personal information on the web every day; protecting this information is critical. I get that, and I’m sure you do, too. Our passwords certainly need to be secure; and with that the need for a certain degree of complexity is inherent.

But like I said above, what frustrates me is unreasonable restrictions on passwords, not requirements.

I don’t mind if my password has to be 8,12, or 20 characters long. I don’t even really mind a requirement for capital letters, or even numbers, really. What pisses me off is when my options for my password are artificially limited by restricting the character set I can use for my password. The relative security of a set of possible passwords might be represented like this:

Where s is the security of the password space (higher is better), x is the number of possible characters that can be used in the password, and L is the length of the password. It is easy to show that you’ll gain more effective security by increasing the length of your password than by increasing the possible character set. It’s relatively simple algebra. That, however, is far from the point here.

From a pure usability standpoint, it’s just plain silly to limit the characters users can put in their passwords. We’ve all seen it - “Passwords may only contain letters and numbers”, or something of the like. As someone who is relatively (relatively) security conscious, I tend to use passphrases for my passwords that contain puncuation like commas, periods, hyphens, and exclamation points. I do this because phrases are easier to remember than a random jumble of letters and numbers, and more secure than a word with some numbers tacked onto the end. Sites that limit my characterset cause me to stray from my secure passphrase, and use something that is typically simpler.

This problem is further compounded by the fact that many sites have different requirements - some only allow some special characters. Some allow only letters and numbers, and some require a certain count of numbers, or have a short limit on length (Password must be 8-16 characters?! What? It’s not that much data to store, DBAs). This is the kind of thing that will have your users writing their passwords on sticky notes, and slapping them on their monitors.

I’ve yet to see a compelling reason to restrict the available character set for passwords for any service - any smart hacker will tune their brute force algorithm to only try passwords in your allowable character set anyway. I personally find it maddening - on any service which I use that requires a strange password, I’d wager that the number of incorrect passwords I enter is 90% higher than otherwise. As you can imagine, that results in a good number of account lockouts, too.

In doing my research for this post, I spoke briefly with a good friend of mine, who works in information security for one of the most influential tech companies on the planet. I think he nailed it rather well - any site with a restricted password, would fit squarely in his “smell test for a site with poor security”. I reckon the same goes for locking accounts, too. Users are already inconvenienced enough by crazy password rules - at the very worst, implement CAPTCHA to fight automated attacks, and don’t send users through inane account-unlock processes.

And really, if you’re not protecting any truly sensitive data, do us all a favor and use OAuth to validate user accounts.

Kinect for Windows SDK - Flailing your arms More Betterer [Part 2]

Continued…

Right, so - in the first bit of this post, we were able to use basic joint tracking with the Kinect SDK to control a UIElement onscreen. We’ll spend some time here polishing this functionality, so that the object we’re tracking onscreen behaves a bit more like those we’re familiar with on the Xbox 360’s Dashboard.

Relatively Speaking

The first thing you’ll notice using example we put together earlier is that in order to move your object from one side of the screen to the other, you have to move your hand across the entire viewable area that the Kinect camera can sense. Clearly, that’s not ideal. In scouring the web for things folks have already done with the Kinect SDK, I’ve come across a few examples of neat tools that make the mistake of leaving cursor tracking set up like this. While it absolutely does function, it’s not convenient for users, and perhaps more importantly, it’s far from what they expect.

As we covered before, the Kinect sensor gives values from roughly -1 to 1 in both X and Y directions (from my own experimentation, I have seen that the device can output values that fall slightly outside these ranges. I believe this comes from estimated positions for joints after they leave the viewable area). WPF Elements which inherit from the System.Windows.Controls.Panel class use an X, Y coordinate system that varies from this slightly - (0,0) is the top left corner of the element, with X values increasing to the right, and Y values increasing downward.

If we’re going to mimic the hand tracking system used on the Xbox 360 Kinect Dashboard, we need to track the hand relative to the rest of the body. From a little bit of my own experimentation, it seems that if we’re tracking the position of the right hand as our cursor, it is best to use the right shoulder as the relative center of the screen. Doing this is actually pretty simple - mathematically, it’s a matter of subtraction to treat the shoulder as a centerpoint in the raw data coming out of the Kinect. This is data can then be sent to the ConvertScaledPosition function (from my previous post) to get a relative screen coordinate.

public static Point GetPositionRelativeToSelf(Microsoft.Research.Kinect.Nui.Vector position, double armLength, Panel panel, SkeletonData skeleton)
{

    Microsoft.Research.Kinect.Nui.Vector centeredPoint = new Microsoft.Research.Kinect.Nui.Vector()
    {
        X = position.X - skeleton.Joints[JointID.ShoulderRight].Position.X,
        Y = position.Y - skeleton.Joints[JointID.ShoulderRight].Position.Y
    };

    double maxlength = armLength * 0.75;

    double xmax = skeleton.Joints[JointID.ShoulderRight].Position.X + maxlength;
    double ymax = skeleton.Joints[JointID.ShoulderRight].Position.Y + maxlength;
    centeredPoint.X = (float)((centeredPoint.X / xmax));
    centeredPoint.Y = (float)((centeredPoint.Y / xmax));

    return ConvertScaledPosition(centeredPoint, panel);
}

The only added requirement for this function is a measurement of the length of our skeleton’s arm. In my own implementation, I track this by keeping tabs on the JointID.ShoulderRight and JointID.ElbowRight joints during each SkeletonFrameReady event -

 // set the arm length value if both the shoulder and elbow are tracked, 
 // and the distance between them is longer than the previously stored value
if (skeleton.Joints[JointID.ShoulderRight].TrackingState == JointTrackingState.Tracked && skeleton.Joints[JointID.ElbowRight].TrackingState == JointTrackingState.Tracked)
{
    double curArmLength = Distance(skeleton.Joints[JointID.ShoulderRight], skeleton.Joints[JointID.ElbowRight]);// +Distance(skeleton.Joints[JointID.ElbowRight], skeleton.Joints[JointID.HandRight]);
     if (armLength < curArmLength) armLength = curArmLength;
}

The armLength value is used to determine the distance that our player’s hand needs to sweep through in order to go from the centerpoint to any edge of the screen. I added a constant multiplier of 0.75 in this example to shorten the sweep slightly for a more natural feel. In your own applications, you may want to play around with that constant a bit to get things to your liking.

In experimentation, I’ve found that with the “right” settings for the the nui.SkeletonEngine.SmoothParameters (again, these values were determined through experimentation), using my hand to point at elements onscreen feels nearly natural.