Idea #11: Location based apps

One of the worst things about the current field of location based apps is that you have to go to them. 4square, facebook, everything is in its own sandbox. What if instead, locations could tell you which apps were up. For example, as you walk through a mall, each stores app blinks in and out as you pass it by. Any apps you have installed, such as 4square tell you if there is anything special for that location. The locations could be marked by cell triangulation, GPS, NFC, low power radio, etc. The trick is to have mobile devices pick up location instantly (no QR code fail or taking pics). I think this would be the real power of a location based service rather than advertising. Money would be made by events and some advertising. Anything annoying could be filtered out easily (location spam). Other specific ideas: - Doorbells that announce who it is - Car starting - Finding your car - Traffic signs - Tolls - Purchasing at stores - Menus and specials - Enhance reality integration

Idea #10: Smelly cell models

Make models of cells that each individual smell like something relating to its function. Idea spawned from this: http://toulousestreet.wordpress.com/2012/02/08/rough-trade/ Will definitely help memory retention as smell is more closely associated with memory

Idea #9: A better way to do online Dating

There are two things very wrong with online dating: 1) You make your own profile and people tend not to know themselves from an external point of view 2) There is a huge trust barrier to overcome between sane people. Conversation without context can feel forced and fake. The first can be solved by having your friends write your profile for you. It'd be interesting for sure, not sure on how well that would work out though. The second is why blind dates work-- both people are stuck in a strange awkward situation that engenders trust. I feel that if your friends choose who you go on dates with, it would be better for this. Its an interesting concept, though I can't imagine it gaining traction in the US (this would work great in India).

Idea #8: Better OpenID

Add a property in your DNS record that gives a url format for OpenID logins. Your OpenId login can then be someone@somewhere[.overtherainbow].biz. You can get the needed url from the DNS record for overtherainbow.biz (and use subdomains appropriately) and redirect/validate the user from there.

This idea must exist somewhere, hmm.

Idea #7: Anti-spam measures

Spam is an issue in many blogs, forums, ims, any communication. It is only an issue if it reaches a real person. Therefore, all actions and modifications to content made by untrusted persons will have to undergo some kind of review in order to not cause a spam problem. In the meantime, their content will have to wait, which is a tradeoff.

1 - Direct connection, XMPP style

Submit comes with token and user@server. That token is validated with that server for that user. Content is trusted to come from that user. No sign in required.

If users@servers are blacklisted, spam will still occur. Users may be required to register then and those registered users whitelisted. Who to trust to register? Lets go onto number 2:

2 - Ring of trust

Any user may register. However, not all are trusted. Trust can earned for user@server by asking server who vouches for user. If we trust any user that vouches for that user, we verify that with that voucher_user@voucher_server. If verified, we assign +rep trust from that user and store it locally with that user's registration. If the circle of trust is outside our scope of registered users, we go to number 3:

3 - Proof of work

User is asked to give a proof of work problem that an average user can handle. If this is solved correctly (maybe a captcha in addition or instead), the user comment is given to manual review. If a manual review is verified, that user is assigned +1 rep from the system.

Caveats

• You still need manual review. If your Proof of work is broken, manual verification can become unwieldy.
• User information must be sent with a comment. That user's server must be up at the time of connection.
• This system only works if trust from the system may be revoked (otherwise mistakes are permanent). Certain highly networked users might become too big to fail and if hacked, cause cascading registration issues (or conversely, solutions). Keeping track of a reputation as well as trust will help mitigate this, as users can be slowly trusted by the system due to reputation rather than relying solely on a brittle trust network.
• The circle of trust implementation here is very basic. The problem is that the server might not know which of its user's vouchers are registered with the site, and this information is private. This results in extraneous information. The 'who can vouch for me' information itself might be private as well. It would likely be better to send along the system name to the user when asking for vouchers. This way they can ask their vouchers who trusts that server and maintain privacy of their vouchers.
• This system does not allow for mass anonymity except through duplicate accounts.

Idea #6: Distributed management for projects

I'm part of a fledging nonprofit called Barrel of Makers. We have a lot of people that want to help us out. However, they have very little time to give, an average of around 5 hours a week (might be 15 hrs some weeks, zero for the next 2). A lot of time they spend on Barrel of Makers is catching up with what has been done and what needs to be done. There is a lot of things going on and once and its not clear where people are needed, what has been done, what needs to be accomplished, or who has worked on what so far.

Basically, we need a management. However, even management has only 15 hours a week to give; its volunteer based! Additionally, the things we do can be very specialized. Often others don't even know whats involved! We can't really afford a single project manager to do what needs to be done yet either.

So we need to distribute the management among everyone, yet make it dead simple (or artist-friendly as I usually put it). Here's my idea:

Have a system where people can create tasks. Tasks can have the following information:
1) What needs to be done?
2) What skills are needed to do it?
3) What other tasks are dependent on this one?
4) What tasks is this task dependent on?
5) When does this need to be done by?
6) When can this task be started?
7) What has been done so far?
8) Who has worked on this?
9) Who is working on this?
10) Is this a project or part of a project?

Really basic. Only "what needs to be done?" is required!

Tasks have the following lifecycle:
- Pending: waiting for #6 above (or circle of trust issues).
- Open: waiting for someone to start the task.
- Assigned: At least one person is working on this.
- Completed: Someone said they completed this.
- Closed: The person that opened this bug or an administrator confirmed it was completed!

Tasks may only be deleted by administrators.

Tasks when filled out may have very details skill requirements, but likely not. As skills are defined, they are added to a skill list. Administrators or their assignees may arrange this into a hierarchy (such as Technology->Computers->Software->Ruby->Rails). The hierarchy has roots, but each node may also have parents-- it can be circular. Skills don't exist until they are used and are automatically hidden after not being used for 18 months. They also auto-tag tasks.

When a user logs in or signs up, they can add skills to their repertoire in the same way they assign needed skills to tasks (clicking through the hierarchy). If a new skill is added under a skill they say they have, they are asked if they are skilled in it the next time they go to their login page (after an admin flags it as ok).

Your home page has 5 sections:
1) Your skills. Only shows if there are new skills.
2) Tasks completed that need to be confirmed by you. Only shows if applicable.
3) Tasks you are working on. Only shows if applicable.
4) Open tasks you can work on in order of priority based on how many people can do that task and the priority of the task itself. Only shows if applicable.
5) Changes to Tasks and Projects you watch. Only shows if applicable. Works like an inbox/feed.

Section 2 is special. In addition to being able to take on a task, you may also change the skill requirements or your own. You may also choose to retain a skill but not get notified of tasks for it (c'mon I code all day long... I don't wanna code in my off time).

The following is on the menu that is always displayed:
1) Logins
2) Skills
3) Messages
4) Presence (available/busy/away/hidden)
5) Settings

Users can log on from either twitter, facebook, google, yahoo, or via openid. No need to roll our own authentication.

For authorization we use a circle of trust. New users may ask you to trust them (you can mark requests as spam). No one can ask administrators to trust them. In addition, you can choose to trust who they trust (called trust by association). You automatically trust anyone they do the same to. In this way, we can allow people to sign up and do whatever yet mark their actions as trusted or untrusted. People can choose not to let other people know they exist unless they are trusted. Yet this also allows new users to quickly join and be assimilated. Administrators are automatically trusted by everyone and everyone automatically trusts everyone an administrator trusts-- So administrators must be very careful who they trust and can delegate trust giving to others. Its easy to understand.

Implementation of who is trusted is relatively simple:
- Maintain groups of mutual (bidirectional) trust by association (maintained when a trust by association is added, may be circular) (Alpha Groups).
- For each Alpha Group, maintain a list of people that the alpha group users trust by association (Beta groups).
- For each Alpha Group, maintain a list of people that are merely trusted (Charlie group).

Asking if you trust a person is akin to asking if they are in any Alpha groups you trust, in any Beta groups you are a part of, and their associated Charlie groups.

Adding trust puts them in a Charlie group. Adding a trust by association puts them in an Beta group if the trust by association is not mutual. If it is mutual, it puts them in a new or existing Alpha group.

Removal of trust is very slow (and rare)! Addition of trust is fast (normal use case)! Verification of trust is fast!

Idea #5: Mobile Keyboards

So I recently got a notion ink adam. As gingerbread, the first tablet-friendly android OS is not out yet, I get to play with 2.2, a phone style one.

What I found is a terrible lack of good keyboards.

For my droid X, swype is amazing. Its among the best in just typing out words, and the feature it is named after, swype is great. A little memory/cpu intensive, but well worth it.

Apparently, swype is a very low level application. Probably to cut down on the cpu/memory intensiveness. So the "drivers" in the program don't work for my OS (it is a custom ROM-- the default that came with the Adam is pretty terrible). I'm pretty positive there are drivers out there that work, but they seem so afraid people will steal their software its not available.

Sadly, they are right. I would mod the hell out of any program they offered open source. Here's why:

• 
  A tablet is not a phone. Having 10 viewable inches is much different than having 3 (or at least that's what she said). I should have room for a number pad, punctuation, and the swype keyboard (if you're going traditional).
  
• 
  You shouldn't target specific hardware with your code. If it doesn't work on any android device, don't bother. The maintenance cost is incredible.
  
• 
  The keyboard user interface should depend on pixel resolution, page resolution, touch sensitivity, availability of another keyboard, availability of voice, and user overrides. I'm not suggesting the user should have to customize it in order to get it to work (the linux approach). I'm suggesting have smart defaults and allow the user to override them.
  
• 
  The technology for determining the word from a swype path shouldn't be coupled to the rest of the keyboard. I sat down and figured out how I would do it (bounding boxes around keys, parse your path weighing circles first, then turns, then straight throughs, parse your dictionary into path trees with 100% weights, add some path trees that skip various letters with less weights, take the user path and traverse your network. Probably also optimize based on the likelihood of straight throughs-- I've noticed skype puts a HUGE weight on circles.) Its complicated, complex, and shouldn't be bundled with the rest of your application! I only hope it separate on their source side! With this technology alone, I could have custom key layouts for games, programming ides, dynamically changing keyboards (with some performance loss), etc. Instead I have to get one complete package built around the piece that would be a pain in the ass to code-- I'd be more than willing to pay for that complex part and its API and forgo the existing!
  
• 
  

Now onto the idea. I'd love to have a keyboard where everytime I type a letter, the only available letters are the ones that make a dictionary word (by default-- you can type one out instead and it gets automatically added to the dictionary). Once you get down to 3 or 4 choices, it just displays those. Common endings like "'s" could be listed on the right as well.

There's a few other ideas I had on this, like a circular keyboard layout based on proximity in your dictionary weighted with how often you use the word (optimal for swype). It'd be cool if the letters slowly moved over time to match your vocabulary. It'd have to be slow though, like a pixel a day.

But I have limited time and I likely won't finish this one. I have another post of touch screen user interfaces that I really want to do.