April 15th 2010
The need for ergonomic keyboards is clear, and so far the only one is the Datahand.
It’s clear that a keyboard should be shaped to your hand if it has any chance of being ergonomic. In fact it should fit you like a glove.
Well that’s my idea, take some of those switches and wires that everyone currently uses to make stupid light-up t-shirts and apply them to something worthwhile.
Take a stretchy “one size fits all” glove, add switches to each finger tip and a usb cable and you could have a product BETTER than the Datahand for a fraction of the price.
Please someone take this idea and get rich, just give me a free pair of your new keyboard gloves.
April 15th 2010
Currently webmail is broken, Squirrelmail looks old and dated, Roundcube got me hacked and Gmail isn’t opensource and on my server.
So here’s how to fix it, write a restful JSON API to perform all the functions like connecting, listing messages, sending emails etc. that works in the same way as CouchDB.
The API could be written in anything but I suggest PHP just for practical deployment everywhere that Squirrelmail worked.
I would call it Davemail and lay it out something like this:
- davemail/api/* - for all the actual requests to access imap
- davemail/themes/* - for the different themes, one per directory that can be easily indexed dynamically so people can just chuck new themes inside and use them without any configuration
- davemail/config/ - Everything inside the config directory would get read by davemail for all the configuration details. That way it could just be a symlink to /etc/davemail/ or wherever. The files would set which imap server to use, login details, email domains accepted etc
Once Davemail takes off the API can be re-written in whatever language or with whatever optimization tricks that we might want in the future and all the themes will still work.
The first step is writing the API, I think we should start with the Squirrelmail IMAP includes and modify them to return the JSON expected.
November 28th 2011
With a lot of “app stores” applications are sandboxed, requiring the user to allow various privileges. I think it’s a great idea but there are two flaws:
- There’s no option to pick and choose the permissions given, it’s all or nothing.
- There are no explanations given for the required permissions, often you can’t make an informed choice.
My suggestion is that Facebook, Google and the likes update their APIs to require an additional parameter when requesting permissions - a reason or explanation. “I need full access to your phone because …”. When you think about it, it’s incredible that it’s not already a requirement! I suggest empowering users to say no if the reason isn’t strong enough, give them the option to say no to permissions they’re not comfortable with.
Oh, one thing worth mentioning; there’s an interesting looking Chrome app to reduce given Facebook permissions. I’ve not tried it but I think the author’s on to something.