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> > > > > . > > > > 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.
