Anonymous users and a possible reworking of the Command-User relationship

1 view
Skip to first unread message

Zeke Sikelianos

unread,
Apr 23, 2008, 2:38:53 PM4/23/08
to Queriac
Gabriel and I are tossing around some ideas about how commands might
be improved..

Zeke says..
Wha about creating a user called 'anon' or something that would be
loaded up with some of the more commonly used commands. Good for
superquick SearchBar installation for users who want privacy, etc..

Gabriel responds..
Having a noncommitted way of querying would be cool to have. If we
moved to a userless command model, it would be a cinch to have a user
with everyone's commands. I'd like to eventually go that route as
relating users to userless-commands would be a great way to relate
similar-minded users, show users how others use their commands and
provide another indicator of how popular a command is.

Zeke responds..
So lemme get this straight.. Commands float by their lonesome and
users connect to them via a join table? And users can add new commands
or just connect to existing ones? I like this idea because it makes
drawing social lines easier, but I wonder about administration of the
commands.. Once a command is created and multiple users use it, who
then is the admin of that command should it need to be changed,
tagged, etc?

ghorner

unread,
Apr 24, 2008, 5:13:36 AM4/24/08
to Queriac
Zeke,
Basically I'm suggesting treating a command much like del.icio
treats its urls, anyone can save(copy) them
and then write down whatever notes and tags they want on it. The
beauty of making commands userless would be to connect users by
command and thus allow them to share what they know about it through
examples, descriptions, fixes and improvements. To address your
concerns:

* A command's tags could simply be an aggregrate of all users' tags
for that command.

* What descriptions and examples show up on a command's page is a
little tricky. Possible solutions could be a wiki,
having command admins (how they're picked is another issue), or voting
on them. I like the last solution since it seems like a good balance
of letting the community drive the site but without having too worry
as much about spam. See urbandictionary.com for a good implementation
of this. Using voting, we could show the highest-voted description and
the top five (arbitrary number) examples.

* As for dealing with broken commands and command improvements (ie
adding more options), I'd use a similar community-driven approach.
Anyone who uses a command would be allowed to post a fix or
improvement to the command's page. As another command user, if I
notice that my command is broken, I'd go to its home page and see if
there are any fixes. If I saw one that worked I'd just copy it to my
local command url. That's an important point. I'd want to allow every
user to keep their own command url. This way when a command's url and
perhaps usage changes, users aren't forced to change unless they want
to.
So how and when would we change a command's official url? We could
keep track of the variant commands and their usage. If the usage got
to be higher than a certain percentage (ie higher than a currently
broken url) the site could automatically change it or flag it for
admin review. If auto-changing, we'd probably want to limit how often
that would happen.
Having said all this, with our current command model there isn't an
easy way to fix commands for everyone and to share improvements.

Hope some of this makes sense,
Gabriel

Zeke Sikelianos

unread,
May 3, 2008, 6:15:42 PM5/3/08
to Queriac
* I like the idea of users voting up other users' command descriptions
and sample usages.. Urban Dictionary style. Also check out the way
del.icio.us handles descriptions and tags for bookmarks:
http://del.icio.us/url/ad643e4c14341b87d9adefdee8d5256e (incidentally
I've got a command for looking up a page's delicious history..
http://queri.ac/zeke/dish/show)

* Like you said, when a users adds a command to their collection, they
should of course be able to choose their own keyword and tags for it,
but I'm not sure about the URL itself. The URL is really the unifying
aspect of the command, the attribute that makes it worth giving
commands independent in the first place. If a user can customize the
URL, what's to stop them from changing their local URL of a Google
search command to http://search.yahoo.com/search?p=(q)? This is of
course a dramatic and unlikely occurence, but still seems shaky to
me..

* More thoughts but I have to run! Gabriel let's skype on this soon.

Obviously users should be able to pick their own keyword for the
Reply all
Reply to author
Forward
0 new messages