Wednesday, April 11, 2012
Save/Export Opera Extensions
If you want to save your Opera Extensions, in case you prefer the older versions - the extensions are located in this folder: C:\Users\USERNAME\AppData\Local\Opera\Opera\widgets. Just replace USERNAME with your windows username.
Sunday, April 8, 2012
A simple form filler/importer for Tax time
If you have some data in a spreadsheet that needs to be entered in to a tax form or software and the software doesn't provide a method to import the data, you can use this simple AutoHotKey script:
^F12:: Loop, read, c:\expenses.csv { LineNumber = %A_Index% Loop, parse, A_LoopReadLine, CSV { SendInput, %A_LoopField% Sleep, 250 Send,{tab} Sleep, 250 } } return
- Download and install AutoHotKey if you don't already have it
- Copy and save the above script as a text file using Notepad or any other text editor - call it "fill.ahk"
- Make a copy of your spreadsheet and remove all the columns that don't need to be entered
- Remove blank rows and any unneeded rows as well
- In the script, change the file path "c:\expenses.csv" in line 2, to a different path if necessary
- Once, the file is ready and in place, double-click the "fill.ahk" file - it shouldn't do anything yet, but you should see a green "H" tray icon
- Switch to your program and page that needs the data entered - I've used for the miscellaneous business expenses entry in TurboTax, but it should work with any program that allows to you move from one field to the next using the "Tab" key
- Press Ctrl and F12 simultaneously - You can change the hotkey in the first line of the script if you like. It should start filling your form
- If you see any erratic behaviour - your program cannot keep up with the speed of data entry, increase the sleep day from 250 to 500 or higher and restart "fill.ahk"
Wednesday, April 14, 2010
Arbitariness
I used to work at a company that shall go unnamed, where we had a mobile application with a simple screen to accept dates. For some reason I don't remember, we didn't use a date picker, but used the on-screen keyboard. When we implemented this screen, Product Management came back to us and said, that the field did not work as designed - it allowed single character days and months - it should only allow 2 character days and months. So instead of typing 1/1/2009, the user would have to type 01/01/2009. Additionally, it also allowed the user to use a hyphen, but it should only allow a slash.
This is plain ridiculous, why should you force the user to type out the unnecessary zeroes? Isn't that what computers are for? To do our work for us? And why force the user to use a slash when they might prefer to use a hyphen? Having rules for the sake of having rules does no one any good, except maybe it feeds the ego of the one making the rules and make for thicker design documents. Especially where usability is concerned, arbitrary rules like this make for a more disappointing user experience. Forcing the user to type more than necessary can break an otherwise pleasant user experience. Now, you might argue that we should have gone with a date picker to begin with, and you'd probably be right, but I'm simply using this as an example of arbitariness.
Another example is password rules - Thou shalt use a mix of upper and lower case and numbers only - no special characters and only up to 8 characters long. And each site or application has it's own rules, it's impossilble for someone to remember. You either resort to Roboform/1Password but most will resort to sticky notes stuck on the monitor. So, the silly rules that were in place to enforce a 'high' standard of security really do the opposite (with the sticky notes, I mean). I'm not saying that there should be no password rules or allow people to have one character passwords - but the rules should be simple enough that people can use any reasonably complex password that they can remember. For example, most password rules will not allow spaces. Why on earth not? Some will not allow special characters, probably because the database queries are not parameterized and some special characters will break the queries - so let's catch them at the UI.
My recommendation for password rules - have a minimum length based on how secure your application needs to be, that's it. No characters required or disallowed. No maximums - at least nothing ridiculous like 8 characters. The maximum length allowed should be fairly long - like 64 or 128 characters.
This is plain ridiculous, why should you force the user to type out the unnecessary zeroes? Isn't that what computers are for? To do our work for us? And why force the user to use a slash when they might prefer to use a hyphen? Having rules for the sake of having rules does no one any good, except maybe it feeds the ego of the one making the rules and make for thicker design documents. Especially where usability is concerned, arbitrary rules like this make for a more disappointing user experience. Forcing the user to type more than necessary can break an otherwise pleasant user experience. Now, you might argue that we should have gone with a date picker to begin with, and you'd probably be right, but I'm simply using this as an example of arbitariness.
Another example is password rules - Thou shalt use a mix of upper and lower case and numbers only - no special characters and only up to 8 characters long. And each site or application has it's own rules, it's impossilble for someone to remember. You either resort to Roboform/1Password but most will resort to sticky notes stuck on the monitor. So, the silly rules that were in place to enforce a 'high' standard of security really do the opposite (with the sticky notes, I mean). I'm not saying that there should be no password rules or allow people to have one character passwords - but the rules should be simple enough that people can use any reasonably complex password that they can remember. For example, most password rules will not allow spaces. Why on earth not? Some will not allow special characters, probably because the database queries are not parameterized and some special characters will break the queries - so let's catch them at the UI.
My recommendation for password rules - have a minimum length based on how secure your application needs to be, that's it. No characters required or disallowed. No maximums - at least nothing ridiculous like 8 characters. The maximum length allowed should be fairly long - like 64 or 128 characters.
Subscribe to:
Posts (Atom)