[mashup-dev] Mashup editor prototype.

[Jonathan Marsh]

Thanks, the Google perspective matches mine pretty well, other than the fact that at some point you get frustrated even with the declarative language and need more expressive power (even in complicated XML languages like XSLT.)

I propose we do an ?edit page which has (at present) two tabs - one for the raw script (a single text block) and a more sophisticated version of the editor I defined.  The user can switch back and forth between the views and we'll keep his code in sync.  Later on if we find there are some simple kinds of services that can be deployed either by parameterizing some common code or by hooking together some building blocks we can provide those as other edit tabs.  So the ?edit query parameter will need a parameter telling which editor to start on: ?edit&view=raw|block.

I'm sure you all realize the end result of this slippery slope is a distributed debugger ;-).

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 

> -----Original Message-----
> From: mashup-dev-bounces at wso2.org [mailto:mashup-dev-bounces at wso2.org]
> On Behalf Of Ajith Ranabahu
> Sent: Saturday, June 02, 2007 1:07 AM
> To: mashup-dev at wso2.org
> Subject: Re: [mashup-dev] Mashup editor prototype.
> 
> Hi Jonathan / all,
> Please see my comments inline.
> Jonathan Marsh wrote:
> > I keep hearing from you all how important editing UIs are.  I’m still
> > not sure I believe it – I think users move quickly from constrained
> UI
> > to full text.  But to explore this a little further, I created a
> > pre-prototype of an editor that structures the javascript source into
> > function blocks and global or local  annotations.  The annotations
> can
> > then be edited in a more constrained fashion - in this case through a
> > forms interface.  Such an interface makes the annotations more
> > discoverable, and provides people help with creating high-quality
> > annotations.  Yet the result can be fairly easily parsed from
> arbitrary
> > user source, edited, and serialized back out as Javascript.
> >
> 
> I'm sure my (somewhat annoying) recent rain of long email on the Google
> mashup editor has a part to play in this ;)  [Sorry - could not contain
> my excitement :) ] Anyway this is cool and you can definitely push it
> out as a tool once the details are figure out and a bit more 'makeup'
> added.
> 
> I agree to the fact that users move from a constrained UI to a full
> text
> editing soon, given that the text equivalent is not horribly complex.
> In
> fact I see people (like me) using the graphical mode and text mode
> interactively in some cases [like in BPEL]. Till yesterday my view of a
> mashup editor was a graphical tool with shapes and arrows [such as the
> yahoo pipes interface] but now I understand that a well designed text
> language can also be quite easy and may be more effective than its
> graphical equivalent.
> 
> I did have a chance to chat with the Google people who made the mashup
> editor and the first question I asked was why not graphical. They told
> me
> 
> 1. People find it not so difficult to use an XMLish language, after
> being exposed to something like HTML.
> 
> 2. The targeted user group is not the most unsavvy computer users but
> the users with a slight bit of computer know how and interest. In other
> words my mother (who knows how to check mail and chat but literally
> nothing else that can be done with a computer) may not be able to make
> a
> mashup with it  but Sanjiva's 10 year old son (who probably knows a bit
> of HTML) will:)
> 
> 3. They may layer a graphical thing over it if there is enough interest
> in the user community but right now there are no plans.
> 
> One other thing that I felt as  important during the presentations was
> the fact that they were emphasizing 'without writing javascript'. I
> guess that in this web 2.0 environment, Javascript is seen as a very
> cool but somewhat a scary experience to the mostly HTML centric people.
> In fact when you actually want a full fledged java script based
> application that works across multiple browsers without a hitch, you
> can
> hardly keep your sanity ! (Our WSAS admin client development team will
> tell you more about it :)).
> 
> Based on that I'm suggesting a bit of improvement - basically two modes
> for the editor. The 'normal' mode displays very little javascript (or
> almost none). Instead it lets you use XML blocks that ultimately
> expands
> to chunks of javascript. These xml blocks may have attributes that can
> control some aspects of the expanded script. The 'expert' mode on the
> other hand is a more techy version where you get more control over the
> javascript. Note that expert mode is not a full text editor but more
> like the tool that Jonathan just published.
> 
> Another suggestion from me is that if there are any plans of serious
> Ajax development for this tool, this would be the right time to adapt a
> framework like GWT or Flex. Both are opensource (well flex is not but
> there is a very good chance that it'll be opensource soon) and I've
> played with GWT  a bit and has a very good impression about it. I've
> been told that flex is also very good.
> 
> Thanks
> 
> Ajith
> 
> _______________________________________________
> Mashup-dev mailing list
> Mashup-dev at wso2.org
> http://www.wso2.org/cgi-bin/mailman/listinfo/mashup-dev