launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #05701
Re: Better UI and AJAX (was Re: next technical architect kanban task)
On 11/17/2010 02:19 PM, Gavin Panella wrote:
> On 17 November 2010 15:07, Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx> wrote:
> ...
>> Also, we have an inconsistent ui and limited, simple ajax controls
>> because we don't have a lot of knowledge on the team for this type
>> of development and we haven't gotten serious about standardizing how
>> we do UI development.
> I avoid some of the js/ajax controls in Launchpad because of that. I
> almost always use the bugtask edit drop-down form instead of the
> status/importance/milestone pickers. If I'm editing more than one
> field it's quicker, and I have a perception of greater reliability
> from ye olde form.
>
> On Launchpad, I think merge proposals are probably the place where
> js/ajax works most predictably and reliably, and I feel comfortable
> there.
YAY!
> I suppose my point is twofold:
>
> - Adding js/ajax doesn't necessarily make things better.
Maybe not from a technical perspective, but it can make the user feel
like the interface is more responsive.
> - If a js/ajax interaction is jarring in any way (for example, not
> updating all related/dependent parts of a page) then things are
> often worse than without the js/ajax interaction.
This can be said about anything. "If $desktop_application is jarring in
any way..." Just don't make it jarring.
>> I continue to hear resistance from developers about having to
>> develop UI skills. Despite all the progress we've made on UI in
>> Launchpad, there is still a long way to go in terms of people's
>> skill in this area and easy of development.
> I have gotten a buzz from doing UI stuff with js/ajax in the past,
> before becoming a Launchpad developer, but I have grown an aversion to
> it since then. It's way too painful, especially compared to the
> non-js/ajax way of doing things in Launchpad, which already isn't a
> walk in the park.
This problem is Launchpad specific, and has a lot to do with the way
that our javascript is structured, the tools around it, and its
testability (or, rather, lack thereof). I've always liked working in
javascript in general. On the U1 team, the javascript moves quickly,
but it doesn't have any tests (we're fixing this now). This lack of
tests has a pretty small risk, because U1 rolls out every hour, so if
something gets broken in a sad way, it doesn't take much time for a fix
to get out to users.
> Put another way, it's probably not just me who likes UI/js/ajax work
> in principle, but shys away from it now because the threshold for
> feeling productive is much too high.
>
We talk a lot about not releasing features until they are "polished."
We've talked about it forever, but with jml's guidance, we're actually
starting to put our money where our mouth is. I think that's going to
cause some pain, because we aren't used to polishing, and we don't have
the tools that make this easy. It's a growing pain, and it's a good pain.
>> Perhaps we need a team within lp like the application-based teams,
>> which is made up of people who care about UI and good JS
>> development, and who are charged with cleaning up the mess we have
>> made. :-)
> I think this idea has merit, though perhaps the fact that I'm thinking
> that is an indicator of quite how difficult it is to work on UI in
> Launchpad. YUI+Windmill has made our js/ajax development sufficiently
> complex that it needs full-time (or very passionate) developers to
> properly engage in it. It is a serious deterrent for those of us who
> want to dip in and get something done.
I've proposed this a few times, but I don't think I had a good idea how
that team would work. At the beginning of our javascript introduction
work, we had a team that was supposed to do just that. Unfortunately,
we had a lot of things that needed to get done (the 3.0 redesign), a
finite time to complete them, and not much interest in UI work (it's
still hard to find people who want to be UI reviewers). I think a good
start is to read my notes from YUIConf. It was good to chat with the
YUI folks and hear the challenges they face, and I have a whole
different outlook on how javascript needs to perform.
I wish I had a "Take courage" speech to give everyone so we can all get
excited about javascript again, but I don't. I am excited, and that's
about all I need to get things done. If you get stuck, I'm here to sort
it out with you, and I'm sure there are a handful of other js/YUI people
that would also love to help where they can.
Cheers,
Paul
Follow ups
References