Hi, Ian. On Wed, Nov 17, 2010 at 6:39 AM, Ian Booth <[email protected]> wrote: > I'm also +1 with Jonathon on ditching non-ajax development. IMHO, > Launchpad's UI needs to be modernised to fit with what today's users > expect from web apps. #1 for me would be adding a whole lot more in-page > editing via smart popups (ie avoiding the need to navigate away from the > current page and back again just to add some data relevant to the > current workflow). The popups we do have also need to be smarter eg with > the bug entry one, compared to what other systems like Atlassian's JIRA > offer, ours is pretty primitive. So in other words, let's focus our > limited resources on taking the product forward and embracing modern > technologies. >
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 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. 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. 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. 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! 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 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. Cheers, deryck -- Deryck Hodge https://launchpad.net/~deryck http://www.devurandom.org/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
