Is it possible to derive statistics about bodies of English text in general from measurements of a dictionary ? For example, if I have a chart of the letter most likely to come before any given letter in the alphabet taken from a dictionary, is that applicable to, say, a journal article?
A dictionary isn't distributed like the usual English text, so I'd say no. Richer metrics would be required to make that sort of translation.
~~~~
Monday, November 5, 2012
Upgrading software
Briefly, upgrade your software only when you want to take advantage of new features or security/stability fixes. That seems obvious, but a lot of people (especially people new to the idea of maintaining a software system) still think that "bleeding-edge" is the way to go, when that just isn't the case. There's nothing to be gained by putting your system in an unstable state at a whim or for the vacuous accomplishment of having the newest thing.
Furthermore, when you do upgrade your software, make sure you have a path back to the previous version so that if something doesn't work well with your system (and there will definitely be times this happens), you can revert without too much hassle. Too many times have I made some install that didn't have a sane un-install procedure--files flying all over the file system, and the only record of where they were supposed to go in a binary executable. Yuck. Avoid using binary executables for setup when you can and it'll save you trouble. And for god's sake, don't make them for your software, but make an install shell script if it wouldn't inconvenience your users. Sure theres the problem of platform incompatibility that comes with that approach, but that's true in any cross-platform system, and there are other ways of dealing with those problems.
Remember, remember the 5th of November...(tee hee)
~~~~
Saturday, November 3, 2012
Adaptive UX
Adaptive user interfaces (AUI) attempt to change to better suit their users. They typically start in some default state defined by the system designer. A user gradually adapts the interface to himself through a negotiation process undertaken during software usage. My first impulse is to reject this sort of interface for lacking consistency, but let's make a brief listing of the requirements for an adaptive UI in a multi-user system. (The multi-user stipulation is aspirational, but presents some considerations that must be made even in single user systems)
Mainly, my concern with this type of interface is that it doesn't allow for users from one instantiation of the system to use another without recalling to himself the initial set-up for the system. That kind of hiccup may only come up with multi-user systems and public terminals, but I think it would be useful for, say, the military to be able to switch out systems without the users needing to retrain the systems to their particular set of optimizations and preferences. There's also the consideration of establishing a common interface between systems. If each user can change the interface dramatically, there's no hope of standardization. Of course, we can say that each system has its own idioms and should be open to specialization for that system; however, for a class of systems that I'm interested in which may be called "general purpose" there is a great potential for making all uses of the system intuitive with a minimum of training. That is my goal anyway: to accelerate the rate at which we can come upon unfamiliar systems and become adept at manipulating them, removing many of the crude attempts at personalization and real-world analogy that plagued interfaces in the '90s and 2000s when computer use became more widespread.
~~~~
Mainly, my concern with this type of interface is that it doesn't allow for users from one instantiation of the system to use another without recalling to himself the initial set-up for the system. That kind of hiccup may only come up with multi-user systems and public terminals, but I think it would be useful for, say, the military to be able to switch out systems without the users needing to retrain the systems to their particular set of optimizations and preferences. There's also the consideration of establishing a common interface between systems. If each user can change the interface dramatically, there's no hope of standardization. Of course, we can say that each system has its own idioms and should be open to specialization for that system; however, for a class of systems that I'm interested in which may be called "general purpose" there is a great potential for making all uses of the system intuitive with a minimum of training. That is my goal anyway: to accelerate the rate at which we can come upon unfamiliar systems and become adept at manipulating them, removing many of the crude attempts at personalization and real-world analogy that plagued interfaces in the '90s and 2000s when computer use became more widespread.
~~~~
Friday, November 2, 2012
$300 prosthetic arm
http://money.cnn.com/video/technology/2012/11/01/ts-prosthetic-arm.cnnmoney/index.html?source=cnn_bin
~~~~
~~~~
Saturday, October 27, 2012
Country rock is pretty cool
Recently found myself a fan of Jason Charles Miller (youtube, homepage). I think I'll explore this genre a bit more.
On another note, I hope to have more long-form posts pretty soon. Have a few drafted posts that need a rereading/polishing.
~~~~
On another note, I hope to have more long-form posts pretty soon. Have a few drafted posts that need a rereading/polishing.
~~~~
Tuesday, October 23, 2012
state and interface
I wonder to what extent you can impose a stateless interface on a system which has an underlying state.
As an example, I might have a "repeat playlist" option built into my music player. There is clearly a state here since when the player is in "repeat mode" it will repeat the track, otherwise not. Typically this would have some sort of toggle item in settings. The other option though is to just give two options "repeat mode on" and "repeat mode off" in the same menu, juxtaposed, with the implication that selecting either one will leave the system in the named state, regardless of what it was before selecting the menu item.
There may be limitations to this when the possible states aren't easily flattened out like in setting some continuous quantity. In general though, I prefer absolute state markers to toggles because they can be engaged with, paradoxically, more certainty and less knowledge of the system-- unlike with mute toggle buttons--what's up with that shit?
~~~~
As an example, I might have a "repeat playlist" option built into my music player. There is clearly a state here since when the player is in "repeat mode" it will repeat the track, otherwise not. Typically this would have some sort of toggle item in settings. The other option though is to just give two options "repeat mode on" and "repeat mode off" in the same menu, juxtaposed, with the implication that selecting either one will leave the system in the named state, regardless of what it was before selecting the menu item.
There may be limitations to this when the possible states aren't easily flattened out like in setting some continuous quantity. In general though, I prefer absolute state markers to toggles because they can be engaged with, paradoxically, more certainty and less knowledge of the system-- unlike with mute toggle buttons--what's up with that shit?
~~~~
Control Your Data
This is just a bit of a reminder to myself to always define my data format manually.
Relying on Ruby to print out hashes in a specific fashion just hosed my test database :{
~~~~
Relying on Ruby to print out hashes in a specific fashion just hosed my test database :{
~~~~
Subscribe to:
Posts (Atom)