launchpad-dev team mailing list archive

[Ian Booth <ian.m.booth@xxxxxxxxx>]

> 
> I wholeheartedly agree with this sentiment that we need to focus on
> making our UI and AJAX work a million times better than it does now.
> However, I don't think we have to sacrifice non-ajax form generation
> to do this.  I read Robert's original blurb as "make it super easy to
> do non-ajax forms so they don't take more time than warranted."  This

I could have worded by email a little better. Personally, I think the
major focus for new development work should be geared towards
modernising the GUI using technologies like ajax, but as you say, we
need to make non-ajax stuff as easy as possible so we don't waste
valuable development effort on that.

> seems the right way forward to me and also seems like a one-off TA
> and/or Foundations team task, not a team-wide effort.  I don't see
> avoiding this work as freeing up much in terms of developer resources.

+1

>  Their are a number of reasons you need non-AJAX still -- search
> engines and users who hate js come to mind.  We have a non-0 amount of
> developers using lp without js enabled, and if bug reports on malone
> are any measure, it's a vocal percentage of our users. :-) Real data
> could say for sure, obviously.  It's just good web practice, though,
> IMO.
> 

+1 on the need to support non-ajax in some usable way, but I don't
understand the mindset of users who *prefer* to stick to a primitive,
awkward gui in this day and age. I guess they also run green screen
80x40 terminals as well :-)

> 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 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'm not an ajax/yui/js expert but would like to increase my skills in
this area and help make Launchpad's UI a better user experience etc. I
can understand UI development is not for everyone but IMHO *all*
developers should have some skills in this area. It's rare on any large
development effort that people can (or should IMHO) just stick to being
"backend" programmers. I would also argue that everyone should have
database skills too.

I guess from my perspective, based on my exposure to date to Launchpad
UI development, it's the lack of standardisation that is perhaps one of
the biggest barriers to effectively and efficiently jumping on board and
getting stuff done. This tends to happen on many large projects.

> In the short term, I plan to draft an email about what I've learned
> having spent 3 weeks now trying to get a YUI upgrade landed, with at
> least some strict requirements for writing new JavaScript.  We need to
> settle on one way to do JavaScript hacking and stick with it.  I'll do
> this whenever I get this branch landed finally!
>

+1. Let's get this preferred approach documented when done and commit to
cleaning up the existing code base so that the various other approaches
used in the past are migrated to the new way.


> However, I would like us to start thinking about new options for
> better dealing with UI.  Perhaps people who don't care about UI
> shouldn't be allowed to touch it. ;)  Perhaps we need a team within lp

I would argue that we *all* should care about UI. Sure, there will be
experts who know more and who can and should be used for technical and
implementation advice, but I personally don't agree with the idea that
people should be excused from having to deal with it. Perhaps once we
have a new standardised approach with good documentation, tooling, etc,
it will be easier to get people onboard.


> 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. :-)  These are just ideas, of course.  And I
> welcome any other ideas, but we have to do something.  As I've already
> written at length about, we invest way too much for such limited
> positive returns on our UI development -- whether that be testing it,
> designing it, or implementing it -- and I'm very serious about seeing
> us fix these issues.
>

Yay. Sad but true, the UI forms a large part of people's opinion of the
quality of a product, especially new users who don't know the cool
things something can do and who may be prepared to forgive a few rough
edges because of that. People do tend to judge a book by its cover and
will form the view that "this product's ui sucks, they can't even get
that right, so how bad must the rest of the product be". I'm not saying
that's necessarily a valid judgement to make, but it tends to be what
people think. Harsh but true. So IMHO we all need to work to ensure
Launchpad provides a great user experience and in today's world, web UI
paradigms from 10 years ago don't suffice.

Later,
Ian