Thursday, December 29, 2011
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).
Monday, December 5, 2011
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.
This idea must exist somewhere, hmm.
Friday, July 1, 2011
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.
Tuesday, April 26, 2011
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!
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!
Sunday, April 3, 2011
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:
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.
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.
Idea #4: Custom item bid app
If the makerspace goes as planned and we can network makers together, there will big a huge supply of custom made stuff available. Etsy has already grow to be successful despite its similarity to ebay because it connects makers together with people.
What etsy doesnt do (as far as I know) is allow for people to submit requests for custom items (like a table that looks like a shark or a desk that allows you to sit or stand without having to adjust monitor arms and such every time).
If you had a large network of makers, you could allow them to submit bids to create these custom items (along with documentation about their bid, such as how they plan on solving the not adjusting the monitor arm problem). Independent makers can peruse these submissions and choose one as they wish. Makers' feedback can be followed and reputations can slowly emerge.
What etsy doesnt do (as far as I know) is allow for people to submit requests for custom items (like a table that looks like a shark or a desk that allows you to sit or stand without having to adjust monitor arms and such every time).
If you had a large network of makers, you could allow them to submit bids to create these custom items (along with documentation about their bid, such as how they plan on solving the not adjusting the monitor arm problem). Independent makers can peruse these submissions and choose one as they wish. Makers' feedback can be followed and reputations can slowly emerge.
Thursday, March 31, 2011
Idea #3: How to start a new OS
Starting a new operating system is damn close to impossible. Mostly because of these things:
The last is inevitable. However, a new OS would allow you to use modern security architecture that over time could actually help make things more secure. One recent OS that has decidedly caught on: android.
The other two are harder.
Android decided to use the linux kernel, probably to help with the driver issues. It kept a java-esce programming language to ease developers in and help make programs SOMEWHAT compatible-- it blew away the archaic and ugly java view/model/event layer with its custom GUI layer (now the cause of a lawsuit).
The other issue is this: Existing operating systems are usually good enough. Exceptions in the past: DOS (hardware changes allowed better security), Windows XP (security architecture problems-- not really solved in vista/7, but the new one is better).
Well why would you even want to make one?
So android started for all of the above. Same with iOS.
I'd love to see a distributed one-- the same "computer" runs at work, home, the cloud, from any PC and resources can be randomly connected/disconnected with no problems. Maybe a smart gui could carry the same program on my phone to my desktop with minimal loss of functionality. This would be ridiculously hard though.
Also if you could actually grow computers (which are crazy inexpensive, can be made locally, but they fail a lot), a fault tolerant distributed system would be awesome. Ya know, like our brains.
- Drivers
- Program compatibility
- Untested security
The last is inevitable. However, a new OS would allow you to use modern security architecture that over time could actually help make things more secure. One recent OS that has decidedly caught on: android.
The other two are harder.
Android decided to use the linux kernel, probably to help with the driver issues. It kept a java-esce programming language to ease developers in and help make programs SOMEWHAT compatible-- it blew away the archaic and ugly java view/model/event layer with its custom GUI layer (now the cause of a lawsuit).
The other issue is this: Existing operating systems are usually good enough. Exceptions in the past: DOS (hardware changes allowed better security), Windows XP (security architecture problems-- not really solved in vista/7, but the new one is better).
Well why would you even want to make one?
- Fun
- Serve a new need (embedded, touch screens, 3D, frequently adding/vanishing resources, reads your mind, injects thoughts into your mind, needs to be distributed, fault tolerant, etc)
- Security through obscurity (or failsafe/stopgap in case of a compromised OS)
- Performance
- Easier for programmers and/or users
So android started for all of the above. Same with iOS.
I'd love to see a distributed one-- the same "computer" runs at work, home, the cloud, from any PC and resources can be randomly connected/disconnected with no problems. Maybe a smart gui could carry the same program on my phone to my desktop with minimal loss of functionality. This would be ridiculously hard though.
Also if you could actually grow computers (which are crazy inexpensive, can be made locally, but they fail a lot), a fault tolerant distributed system would be awesome. Ya know, like our brains.
Monday, March 28, 2011
Idea #2: Constraint Based GUIs
GUIs are hard.
Not hard to learn. Hard to do what you want.
When I was doing CAD in High School I found Inventor. It offered constraint based modeling-- one of the best things ever (AutoCAD feels silly afterwards). It let me know if my system was over constrained or under-constrained, which is great for a new designer. It also lets you take the least measurements needed (just sketch things up, constrain the shape, then start doings specifying some lengths!).
I haven't found a GUI that does something similar.
You could have constraints like "Text size must be readable"... which means different things to different people.
You could have constraints like absolute positioning or this box must contain some other box.
This would only be good for structure, not content or styling!
Best of all you can detect over/under constrained problems... before it looks ugly! I suppose it could warn you on the minimum screen size needed as well (maybe switch skins based on constraints)!
Non-exhaustive list of possible constraints:
contains all of _
is contained by _
does not overlap
does not rotate
southwest of _
east of _
is _ degrees/radians from _
's center is _ degrees/radians from center of _
always shows
attached to _
cannot be resized
takes up the maximum size
takes up the minimum size
takes up _
is bounded by a rectangle [_ by _]
is bounded by a circle [with radius/diameter _]
has a buffer of _ [[around it]/[inside it]]
has a readable color
smallest readable by user
bigger than _ by _
repeats _ by _ (infinity is valid)
may repeat _
Example:
So on and so forth.
For the style, you'd have to uniquely name everything. I suppose I left out repeating blocks.
This could be really interesting as something modeled this way could literally have a image floating around the screen as the text moves around it. It would also make it much easier for moving of components from somewhere else.
I'd probably copy the syntax of this from haml, the most beautiful of the sgml producing formatting languages.
Not hard to learn. Hard to do what you want.
When I was doing CAD in High School I found Inventor. It offered constraint based modeling-- one of the best things ever (AutoCAD feels silly afterwards). It let me know if my system was over constrained or under-constrained, which is great for a new designer. It also lets you take the least measurements needed (just sketch things up, constrain the shape, then start doings specifying some lengths!).
I haven't found a GUI that does something similar.
You could have constraints like "Text size must be readable"... which means different things to different people.
You could have constraints like absolute positioning or this box must contain some other box.
This would only be good for structure, not content or styling!
Best of all you can detect over/under constrained problems... before it looks ugly! I suppose it could warn you on the minimum screen size needed as well (maybe switch skins based on constraints)!
Non-exhaustive list of possible constraints:
contains all of _
is contained by _
does not overlap
does not rotate
southwest of _
east of _
is _ degrees/radians from _
's center is _ degrees/radians from center of _
always shows
attached to _
cannot be resized
takes up the maximum size
takes up the minimum size
takes up _
is bounded by a rectangle [_ by _]
is bounded by a circle [with radius/diameter _]
has a buffer of _ [[around it]/[inside it]]
has a readable color
smallest readable by user
bigger than _ by _
repeats _ by _ (infinity is valid)
may repeat _
Example:
BlogPost contains Menu, EditBox, Buttons, and ReturnLink
BlogPost takes up maximum screen
Menu at top
EditBox south of MenuBox
Buttons south of EditBox
ReturnLink south of Buttons
Menu,EditBox,Buttons,ReturnLink want to be West, want to take up the minimum size, and do not overlap.
So on and so forth.
For the style, you'd have to uniquely name everything. I suppose I left out repeating blocks.
This could be really interesting as something modeled this way could literally have a image floating around the screen as the text moves around it. It would also make it much easier for moving of components from somewhere else.
I'd probably copy the syntax of this from haml, the most beautiful of the sgml producing formatting languages.
Friday, March 25, 2011
Idea #1: Peer reviewed blogging
Everyone knows of digg, slashdot, and others where people submit stories and people vote them up down and provide commentary.
The first group to do this was academia. They would submit articles to committees, who would review them, and choose to publish them in their prestigious journal-- or not.
Crowdsurfing does cool things, but it serves the common denominator.
I think a better model might be to have the people that actually submit stories get reviewed by 6 other people. In turn for a chance to have your article reviewed you review 6 other peoples and say yes or no. By review I mean thumb and article up or down.
Normally this would develop a culture where everyone thumbs everyone else up. However, here's the twist. You can only thumb half of them up. The more your rating varies from 50%, the less you are weighted. The more highly others rank your articles, the more your articles are rated.
Another aspect to your score might be the score readers give your articles, your tags, and how many readers articles you support or write garner!
Just an idea.
The first group to do this was academia. They would submit articles to committees, who would review them, and choose to publish them in their prestigious journal-- or not.
Crowdsurfing does cool things, but it serves the common denominator.
I think a better model might be to have the people that actually submit stories get reviewed by 6 other people. In turn for a chance to have your article reviewed you review 6 other peoples and say yes or no. By review I mean thumb and article up or down.
Normally this would develop a culture where everyone thumbs everyone else up. However, here's the twist. You can only thumb half of them up. The more your rating varies from 50%, the less you are weighted. The more highly others rank your articles, the more your articles are rated.
Another aspect to your score might be the score readers give your articles, your tags, and how many readers articles you support or write garner!
Just an idea.
Subscribe to:
Posts (Atom)