Remember my last post? I said I was going to give the Swype beta a try? That was back in January. I'm still using it and can't see a reason not to continue with it. It's a very good blend of gesture based input with the keyboard layout I expect. That's not saying it's perfect. I still sometimes struggle with things like entering times because including the colon (:) triggers the auto complete. I also wish entering "your" would allow me to select "you're" from the options of what you might have meant. But these are quibbles and on the whole I'm very happy.
I thought you might like to know.
Thursday, April 7, 2011
Tuesday, January 18, 2011
Input on mobile devices
Since the last time I posted (I know, way too long ago) I've changed my phone from a Palm Treo 800w (Windows Mobile 6) to a HTC EVO (Android). I've got to say I love my new phone. It does everything I want it to do seamlessly. This includes managing my Google calendar and Gmail, Twitter, Facebook, etc.
One of the things I was apprehensive about in making the switch, though, was the lack of a physical keyboard. I've always benefited from the tactile response you get from actual buttons. For example, I drive a first generation Prius. In my car the radio station presets are exposed as "buttons" on the center display screen - so no physical buttons. To change the radio station I have to press the "Audio" button on the dashboard (that's a physical button) then look on the screen to press the preset station "button" to change the station.
Which means taking my eyes off the road.
While driving.
So I've learned to hate the on-screen buttons (and to content myself with one radio station that I rarely switch from). What I didn't anticipate with the phone, however, was the fun I could have experimenting with different input methods you get when the physical keyboard is eliminated.
The EVO comes with a standard on-screen QWERTY keyboard. There are options for having the phone vibrate for each key press (do you call it a key press when there are no keys?) to provide that tactile response I mentioned (although, again, there's no way to determine which "key" you're on without looking at the screen).
And I was merrily using that when one of my co-workers, Pat, directed me to 8Pen. Now I could try to describe 8Pen, but really you should go to their web site and watch the introductory video. Go ahead and watch it, I'll wait...
Pretty cool, right? I thought they made a compelling case for ditching the QWERTY keyboard. So I tried it. I installed 8Pen and made a decision to go cold turkey. I knew there would be a learning curve and it might take a while to adapt. It has a number of improvements over the default keyboard. For example, the auto-complete functionality is much than the default. However, after a month without using the default keyboard I decided to ditch 8Pen. It's not that it doesn't work as advertised - it does. But even after a month I was still being slowed down trying to find certain letters.
Why was that? Why am I measurably faster using a QWERTY keyboard? I think the answer is explained by a blog post I read several years ago. Back when I still read the JoelOnSoftware blog this post resonated with me. The central point that I took from it is users have a positive or negative experience with software depending on how that software conforms to their previous experiences. That bias is called the user model. Well, after 25+ years of typing on QWERTY keyboards I'm really efficient at locating letters in that arrangement. Additionally, because I continued to use a QWERTY keyboard throughout the day on my laptop and desktop my assimilation of the 8Pen layout was constantly being subverted. So I cried "uncle."
The good news is that Pat came to my rescue with a link to the Swype beta. It has the benefit of the QWERTY layout while embracing a gesture based style of input. It's been a week and so far I'm really enjoying it. It's not perfect either, of course, but I'm willing to at least give it a month like I did 8Pen.
Stay tuned.
One of the things I was apprehensive about in making the switch, though, was the lack of a physical keyboard. I've always benefited from the tactile response you get from actual buttons. For example, I drive a first generation Prius. In my car the radio station presets are exposed as "buttons" on the center display screen - so no physical buttons. To change the radio station I have to press the "Audio" button on the dashboard (that's a physical button) then look on the screen to press the preset station "button" to change the station.
Which means taking my eyes off the road.
While driving.
So I've learned to hate the on-screen buttons (and to content myself with one radio station that I rarely switch from). What I didn't anticipate with the phone, however, was the fun I could have experimenting with different input methods you get when the physical keyboard is eliminated.
The EVO comes with a standard on-screen QWERTY keyboard. There are options for having the phone vibrate for each key press (do you call it a key press when there are no keys?) to provide that tactile response I mentioned (although, again, there's no way to determine which "key" you're on without looking at the screen).
And I was merrily using that when one of my co-workers, Pat, directed me to 8Pen. Now I could try to describe 8Pen, but really you should go to their web site and watch the introductory video. Go ahead and watch it, I'll wait...
Pretty cool, right? I thought they made a compelling case for ditching the QWERTY keyboard. So I tried it. I installed 8Pen and made a decision to go cold turkey. I knew there would be a learning curve and it might take a while to adapt. It has a number of improvements over the default keyboard. For example, the auto-complete functionality is much than the default. However, after a month without using the default keyboard I decided to ditch 8Pen. It's not that it doesn't work as advertised - it does. But even after a month I was still being slowed down trying to find certain letters.
Why was that? Why am I measurably faster using a QWERTY keyboard? I think the answer is explained by a blog post I read several years ago. Back when I still read the JoelOnSoftware blog this post resonated with me. The central point that I took from it is users have a positive or negative experience with software depending on how that software conforms to their previous experiences. That bias is called the user model. Well, after 25+ years of typing on QWERTY keyboards I'm really efficient at locating letters in that arrangement. Additionally, because I continued to use a QWERTY keyboard throughout the day on my laptop and desktop my assimilation of the 8Pen layout was constantly being subverted. So I cried "uncle."
The good news is that Pat came to my rescue with a link to the Swype beta. It has the benefit of the QWERTY layout while embracing a gesture based style of input. It's been a week and so far I'm really enjoying it. It's not perfect either, of course, but I'm willing to at least give it a month like I did 8Pen.
Stay tuned.
Tuesday, July 13, 2010
Turning off the comments on this thing
I've decided to turn off comments on the blog because comments were running 8 spam links for every 1 meaningful comment. If you want to send me feedback about a post feel free to send me something on Twitter.
Tuesday, July 6, 2010
Where did FxCop go?
I've used FxCop to do code analysis for years now (and brow beat co-workers to use it, too). I've incorporated it into my automated build scripts and use it every time I do a code review. So imagine my dismay when I heard the FxCop site was no longer running (I usually get there from the MSDN Library entry about FxCop). I wasn't sure if this was just a case of a dead link, but then I read this article by Jonathan Allen on InfoQ. Apparently FxCop 1.36 was yanked from the Microsoft Downloads site. Jonathan's article directs the reader to the Windows 7 SDK. The Microsoft Download site has an entry for FxCop 10 but it turns out that just gets you a readme.txt file instructing you to download the Windows SDK for Windows 7.
That's not terribly useful. There isn't even a link to where to get the Windows 7 SDK in the readme file.
So thank you to InfoQ and Jonathan for providing the link.
BTW, it seems the only reason the older FxCop version was removed was because the functionality FxCop provides is in some versions of VS2010. This is going to have an impact on my automated build scripts so I expect I'll be following the advice from this blog post from Travis Illig's blog at some point - so thanks to him, too.
That's not terribly useful. There isn't even a link to where to get the Windows 7 SDK in the readme file.
So thank you to InfoQ and Jonathan for providing the link.
BTW, it seems the only reason the older FxCop version was removed was because the functionality FxCop provides is in some versions of VS2010. This is going to have an impact on my automated build scripts so I expect I'll be following the advice from this blog post from Travis Illig's blog at some point - so thanks to him, too.
Monday, June 14, 2010
Which came first, the variable or the literal?
Today I received the feedback from a code review one of my peers did of my code and they asked a question about a particular coding style technique I use. Specifically they asked why when comparing a variable to a literal value I always put the literal value on the left side of the operator? Put another way, why do I do this:
if(null == someVariable)
instead of this:
if(someVariable == null)
After all, this person pointed out, the second method is more easily read as "someVariable equals null" as opposed to "null is equal to the value of someVariable." I think that's a fair point and while I'm a big proponent of increasing the readability of code this is an instance where I'll take the hit.
My habit of putting the literal value before the variable comes from dealing with Javascript. When coding Javascript I might check to see if a value is set to zero, like this:
if(someVariable = 0)
Maybe that looks good to me because I haven't had my third espresso of the day - but it introduces a bug in my code. I fat-fingered the operator and put = instead of ==. So now the statement isn't doing an evaluation, it's doing an assignment. I'm not going to catch that as part of a compile because Javascript is not compiled. And it's not going to raise a run-time error because it's syntactically valid.
But it's not going to do what I want it to do.
Because I've been burned by this in the past I got in the habit of putting the literal on the left side of the operator. Because while I still won't get any compile-time love I will get a run-time error when the code says:
if(0 = someVariable)
Yes, the code review was being done against some of my C# code so the same risk isn't there. But I don't feel like changing this habit from language to language. Especially where I'm doing ASP.NET and am jumping between C# and Javascript all day anyway.
if(null == someVariable)
instead of this:
if(someVariable == null)
After all, this person pointed out, the second method is more easily read as "someVariable equals null" as opposed to "null is equal to the value of someVariable." I think that's a fair point and while I'm a big proponent of increasing the readability of code this is an instance where I'll take the hit.
My habit of putting the literal value before the variable comes from dealing with Javascript. When coding Javascript I might check to see if a value is set to zero, like this:
if(someVariable = 0)
Maybe that looks good to me because I haven't had my third espresso of the day - but it introduces a bug in my code. I fat-fingered the operator and put = instead of ==. So now the statement isn't doing an evaluation, it's doing an assignment. I'm not going to catch that as part of a compile because Javascript is not compiled. And it's not going to raise a run-time error because it's syntactically valid.
But it's not going to do what I want it to do.
Because I've been burned by this in the past I got in the habit of putting the literal on the left side of the operator. Because while I still won't get any compile-time love I will get a run-time error when the code says:
if(0 = someVariable)
Yes, the code review was being done against some of my C# code so the same risk isn't there. But I don't feel like changing this habit from language to language. Especially where I'm doing ASP.NET and am jumping between C# and Javascript all day anyway.
Friday, May 21, 2010
Follow up on CamStudio
I've done a couple of videos for work now using CamStudio (as mentioned in my previous post). One thing is the resulting AVI files are HUGE. I'm trying to get familiar with how to compress the video and found this tutorial from Video Tutes helpful so I figured I would share.
Wednesday, April 14, 2010
Free screen capture tool: CamStudio
Yesterday I gave a 2 hour presentation to all our new developers about some of the tools we use. Unfortunately, I neglected to mention one of them. Rather than schedule another meeting for a 5 minute topic I decided to record a quick screen cast.
I thought it would be quick, anyway.
I've done this in the past using Snagit which has a video capture function. But for whatever reason the act of recording the screen caused my actions to suffer a terrible delay. For example, click a menu item and wait 45 seconds for the menu to react. Not good. I lost about an hour trying to get the system to work correctly while recording without success.
Over lunch a coworker suggested using a free tool called CamStudio. I installed it, changed a couple of settings to record audio and boom! Done. Free and easy. Two of my favorite four letter words.
Subscribe to:
Posts (Atom)