Cool. I'm finding it really difficult to get time to work on stuff now,
but it's good to know it will be documented.
--
Wim
On 30/11/2010 12:57 a.m., David Hearnden wrote:
Wim,
I'll be documenting exactly how the private user-data wavelet works
later this week. If you need more information sooner, then feel free
to ask.
-David
On Nov 28, 4:05 pm, Nemo157<[email protected]> wrote:
This actually touches on some of the things I've been thinking about
recently. As well as having a strongly defined client-server protocol what
we also need is a defined metadata format / "client-client" protocol. The
format of the private wavelet containing information on which blips are read
and unread should be well specified so that someone utilising various
clients is able to keep things such as unread status constant across all
their clients. This would involve:
1. Finding the private wavelet.
2. Decoding the data stored in it.
3. Well defined fallbacks for missing data and/or unsupported extensions.
If my current project actually progresses over the summer I'll probably
have a lot more to say on this subject in a few months.
--
Wim
On Sun, Nov 28, 2010 at 5:02 PM, Michael MacFadden<
[email protected]> wrote:
I think if we get the infrastructure right, we can support many
different kinds of user interfaces. I think there are some challenges
of course but a scenario where the core components could be reused as
building blocks from which to compose / customize / and skinned would
be great.
I think the question becomes how these customizations happen. If we
had a strong client-server protocol (not saying we don't, I just don't
know at this point) then the packaging of a new ui could be completely
separate from the WiaB distribution. The other alternative woud be to
have some sort of plugin architecture that would allow skinned or
customized UIs to be deployed with in wave in the box. Not sure what
the right path is.
Currently most of the reusable stuff for the WiaB client is ultimately
provided through GWT. In other worse the javascript APIs come from
compiled GWT. I am wondering if the GWT compiled APIs can be
leveraged by raw HTML / CSS/ Javascript apps?
There are already people asking about leveraging the client-server
protocol for other web apps or even desktop and/or mobile apps. If we
draw a correlation to email protocols then I think what we have is
something like:
Federation Protocol ~= SMTP
Client Server Protocol ~= IMAP / POP
I think it is widely understood that the federation protocol needs to
be robust and standardized. I am not so sure the client server
protocol is viewed in the same way. At the moment, it is viewed by
some as specific to the client / sever implementation pair. I haven't
heard to much talk about a single server supporting many different
clients through a standard protocol. This is apparent in the fact
that we don't even have a real name for the protocol (i.e. we just
call it client-server, vs server-server which we call Federation).
I will start a wiki page where we can start tracking some of these
issue and objectives and where people can post their mockups and
ideas.
Michael
On Nov 27, 8:04 pm, Kai Chang<[email protected]> wrote:
Pictures definitely work for some applications. Re-reading the "generic"
comment earlier, I think the implication was GWave tried to be a
Jack-of-all-Trades. It could kind of do many, many things. But it
wasn't a
great document editor, or social network, or micro-blog, or wiki, or
project
management tool, etc.
Wikipedia describes GWave as: "*a web-based computing platform and
communications protocol, designed to merge key features of media like
e-mail, instant messaging, wikis, and social networking*."
The underlying protocol has great advantages for all these applications.
However, creating a single interface that fuses all these "features" and
maintains its own conceptual integrity may not be feasible.
On Sat, Nov 27, 2010 at 3:41 PM, Gamer_Z.<[email protected]> wrote:
I personally liked the idea of using someone's picture. It seems to
make sense, dragging someone's head to a wave to bring him or her to
the discussion.
Also, I agree that the use of GWT is the one of the biggest problems
(at least for me). I am glad to create mockups in HTML+CSS, but I do
not understand GWT.
On Nov 27, 6:24 pm, Kai Chang<[email protected]> wrote:
A wiki is a great idea. Then we could tackle many disparate
problems,
and
start grouping similar ideas together into a coherent interface.
I don't feel wave.google.com had a generic interface. It was
strongly
influenced by Gmail/Facebook, and threaded comments like Reddit.
Profile
pics, for instance, are used in at least four contexts: Contact
list,
Wave
Inbox, at the top of a wave (participants list), and within a wave.
So
you
can easily be looking at a screen in Gwave where you see the same pic
4
times. To me, that screams Facebook.
One thing I would like to see is more designer/developer friendly
tools
for
creating and modifying the interface. Torben's Wala-compiler is
headed
in
the right direction. Java/GWT is an incredibly high barrier to entry
for
UI
designers.
I'm interested in creating HTML/CSS/JS mockups of design ideas.
Still
working on Tensor, which is a study in tree structures and contextual
blips
(eg, an issue tracker wavelet where blips are tasks).
Ideally, WIAB should eventually ship with multiple skins/interfaces.
These
should serve as starting points of different interface paradigms for
people
looking to customize WIAB.
Also, slightly too specific, how feasible would a Wiki-like two
column
revision history be to build? GWave's Playback was cool, but not
very
practical for reviewing groups of changes.
On Sat, Nov 27, 2010 at 1:54 PM, Michael MacFadden<
[email protected]> wrote:
Again I agree completely. Maybe I should set up a wiki page where
people can most mock ups and ideas for us to discuss. As I said I
think the more diverse ideas we can look at, the better off we will
be.
Michael
On Nov 27, 2:23 pm, x00<[email protected]> wrote:
Figure out aims (already started), project initial user base, get
UI
people on board, don't be limited by gwt, look into methods of
hooking
up interfaces, schematics, schematics, mockups, etc.
*more detail*
Wave is kind of user centric at the moment. I know it sounds
contradictory making a user interface other than user centric.
But it
isn't about making it less user friendly, on the contrary, more
bout
striking the balance between task and the users (which obviously
are
an important part of getting the task done). I created a
schematic
for
an interface that was more task centric, and it was actually like
a
walk-through experience (wave agnostic). It is too specific for
WAIB,
but the general idea that social media for the sake of social
media,
whilst good for reaping personal information, is ultimately not
uniquely useful to the users other than status reasons, whereas
things
like wave are about getting things done and communicating ideas
collaboratively. Obviously there are other synonyms for "task"
but
you
get the idea. I think architecture that reflects the aim to
collaborate on something makes sense.
I know I said this before, but I'll say it again. “Conversation”
is
just a default communication. It is one type of collaborative
communication amongst many possibilities. Granted it will be a
popular
one that would be used along side app doc and other things.
However
it would be good in the long term to build all models and their
interfaces with api for that.
--
You received this message because you are subscribed to the Google
Groups
"Wave Protocol" group.
To post to this group, send email to
[email protected].
To unsubscribe from this group, send email to
[email protected]<wave-protocol%2bunsubscr...@goog
legroups.com>
<wave-protocol%2bunsubscr...@goog legroups.com>
<wave-protocol%2bunsubscr...@goog legroups.com>
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
--
You received this message because you are subscribed to the Google
Groups
"Wave Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected]<wave-protocol%2bunsubscr...@goog
legroups.com>
<wave-protocol%2bunsubscr...@goog legroups.com>
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
--
You received this message because you are subscribed to the Google Groups
"Wave Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected]<wave-protocol%2bunsubscr...@goog
legroups.com>
.
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
--
You received this message because you are subscribed to the Google Groups "Wave
Protocol" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/wave-protocol?hl=en.
