[vagueware] Re: is less really more?

  • From: verbose@xxxxxxxxxx <verbose@xxxxxxxxxx>
  • To: <vagueware@xxxxxxxxxxxxx>
  • Date: Tue, 5 Oct 2004 15:32:00 -0700 (PDT)

"And as life keeps getting in the way I doubt we can motivate each other."

i don't. projects motivate me. and community projects motivate me even more.

"But if it happened to go tits-up then let's face it, it'll be seen as Wiggy's 
failure."

speak for yourself. due to how vagueware appeals to me, i've done quite a lot 
of evangelizing when people ask me what i've been doing/interested in/working 
on. also, my girlfriend gets soundingboard duties. so vagueware's failure to me 
carries social(professional) and personal consequences.

"But once we've decided the direction, or if we can't decide and Wiggy 
dictates, we stick to the plan."

definetely. he's the leader. just that we're the team. when the shit hits the 
fan, i'll definetely back the wig.

"locking-is-a-pain-in-the-arse"

locking is worth all the pain

"The sample SWF may look cool, but I doubt you can export the spline info. 
Making it a little bit useless - even if I could be bothered to get it running 
on my desktop."

heh heh.. that was just an example. the spline info is not exportable, but it 
doesn't have to be. just the relationships. the spline can be re-made according 
to something in the backend. xml (svg) is much more modular anyway.

what i'd like to see is a very modular and comprehensive spec for how 
backend/frontend communication works. that way many people can code all sorts 
of frontends: in flash, in xhtml, in svg, thinclients, libraries, etc.

"But, well, a little bit of initial focus would probably make it more likely to 
hit critical mass."

i agree. but --to me-- the most important thing is vagueware the tool. the 
world isn't ready or doesn't yet have the need for a wikipedia that hosts their 
content/spec/policy vapourware.

"I'd kill for some decent webby flowcharting. And if I could
click on a box and see a wiki explaining it... well...  I could think of a 1001 
different uses."

yeah, mindmaps are cool, but flowcharts are the other thing. pretty much we've 
got the 3 main abstractions right here:

represents hypertext     > html
represents relationships > mindmap
represents procedures    > flowchart

which fits into which?
the data represented in mindmaps and flowcharts can both be represented 
(exported, parsed, rendered) in hypertext. but automatizing the making of 
hypertext into a mindmap is much more difficult. and making hypertext into a 
flowchart, is much less feasable since 1)it requieres much more human 
interaction and 2)you mostly don't do this anyway.

therefore i propose the following:

'hypertext' abstraction is mostly used for "rendering" of documents inside of 
projects

editing of relationships can only be done in 

actually

"But we also need a meme dictionary to explain word-concepts (like, for example 
meme, singularity and bikeshed ;-0  ) to newbies."

i wholeheartedly agree on this. but i think we need a metavagueware wiki 
separate from vagueware.com, since i don't think its encouraging for normal 
users to see that the thing is still in development. if you open a brand new 
theme park that's under construction and the visitors can't go on the rides, 
then you hide the rides to prevent disillusion.

"so you build a "groupware primitive library" so that if someone wants their 
project to have a specific groupware function that doesn't yet exists, they can 
use the parts to piece it toghether." [my text]

"primitives... a paradigm pallet as it were.... sounds good."

no, not a paradigm pallet, more like a library to build project templates.

"But the corollary to imitation is the the lack of innovation."

this is not about imitation.

except for wikipedia and a few php-based bulletin boards, i haven't used any 
collaborative software implementations.

some of the future users of vagueware might ask for a feature from lotusnotes, 
others might ask for a feature from slashcode, others from project open. but, 
are we going to code each and every one of these features as they're requested 
or as they become essential? i say we don't have to.

if you were to implement all the features of all the collaborative sofwtare 
solutions into one thing, there would be a lot of redunancy issues. a lot of 
stuff wouldn't work not just because its called differently or is implemented 
differently, but also because of the level of detail.

now what if the level of detail was broken down into the smallest possible 
pieces? most organic stuff is made out of proteins, which are themselves made 
by rna/dna, which is made out of four aminoacids. so instead of having to code 
each feature, you just give people access to the dna, and let them make "build" 
their own features. my guess is that every feature imaginable must come from a 
pallette of about 10 to 16 "primitives" that you can piece toghether to form 
all the functions. the trick is finding them.

-carlos

Other related posts: