A couple comments inline. On Tue, Apr 17, 2012 at 12:00:18PM +0100, Bert Pareyn wrote: > Hey guys, > I've consolidated the suggestions James, Nico, Christian and I have to > improve performance and optimize the UI. Most of the optimizations are > nice to have but performance should get priority, especially widget > loading. > Performance: > - Reduce the number of requests we do in the UI > - Widget loading should move over to the backend, this would be > the greatest win. Currently the widgets that return on every page are > loaded through the top navigation.
Yes, this is a problem for developers who would submit widgets to the
widget library that should load on every page, you'd have to have
deployers patch topnavigation. A setting like the ones that say which
dashboards and if pages can contain this widget would be better.
> - Reduce number of POSTS for permissions
> - Preferably we'd move this over to the backend and only
> do one post (public, private, logged-in). That would allow us to remove
> all ACL handling from the front-end and make things more consistent across
> the UI. Currently we do at about 3-4 POSTs.
> - When adding a user we could then also limit the
> UI to sending out data like {'user1': 'manager'}
> - Reduce number of requests when adding content. We go through a
> loop that posts with each content item we upload:
> 1. Create the file (only one we can't batch)
> 2. Post description and basic parameters (batch this
> together with all other files)
> 3. Tag the content (batch this together with all other
> files)
> 4. Modify ACL's (preferably move this server side)
> A nice side effect of this is that we'll be able to modify the
> progress indicator to show the task that is currently being processed
> (also add real progress. e.g. uploaded 3 of 14 files).
> - Remove unnecessary files and CSS/HTML/JS from the code base to make it
> lighter
> - Loads of unused CSS files
> - Review all CSS and grep for usage
I think we should really consider using some kind of CSS framework like
SASS http://sass-lang.com/ to simplify our CSS.
> Optimizations and nice to haves:
> - CSS
> - Use CSS sprites and investigate how to best structure these.
> - Formatting (trivial but best done in one go)
> - For every clickable element we should have a focus (most of them
> have hovers)
> - Permissions
> - Consistency checks (labels etc.)
> - Use API everywhere (not currently doing this)
> - Inbox
> - Cache messages
> - Currently inbox gets reloaded each time you navigate
> between pages (e.g. inbox -> sent -> inbox).
> - Instead of doing a periodic GET for system/me we could fetch the
> inbox feed and update the message counts in the top and left hand nav. Not
> really an optimization but a win nevertheless.
> - Documentation
> - Widget SDK
> - Complete UI API documentation
> - Cross browser guidelines
> - How to submit your widget (workflow)
> - Accessibility
> - We have quite a lot of open and resolved tickets for
> accessibility. We should look into existing frameworks that can help us in
> do the work.
> - Core UI Dev
> - Get rid of global variables
> - Avoid using JavaScript in places like hovers, click events on
> divs (should be button/anchor elements) and use relative positioning where
> possible.
> - Try to avoid areas in the UI that need to be revisited later on
> because of a pending back-end fix
> - Go from $.bind/$.live to $.on
> - Reusable templates
> - Page layouts (similar to what we have in the Widget
> Library)
> - Common template structures (e.g. rendering lists)
> - Create API functions
> - Drag and drop functionality
> - Collections
> - Uploading content
> - Counts
> - Counts scattered all over the code base
> - Find way to consolidate, improve handling
> - Progress indication
> - Especially in the content area (large images, video�s,�)
> should show indication that the content is loading
> - Sluggish rendering
> - Review # requests per page, use tools like YSlow, Speed
> Index and Speed Tracer
> - More unit tests + incorporate that in our daily/weekly development cycle
> - Always part of code review and should be done before each pull
> request
> - Automate unit tests
> - Automated tests!
> - Git workflow
> - When submitting PR:
> - Include PR link in ticket + include ticket in PR
> - Commit style: �SAKIII-XXXX describing the work done�
> - Go into issues tab on Github and set �to review� and
> �version� labels
> - If pending merge gets more work done, update labels to
> �to review� or other appropriate labels.
> - Bert
> On 17 Apr 2012, at 06:29, Christian Vuerings wrote:
>
> Just like the "Making a better server" thread started by Zach, I've been
> thinking about how we can make the front-end better.
> Lately many people have been wondering about how we might scale/perform
> better.
> IMO one of the best things we can do is the following (credits to Nico,
> hope I explain it correctly).
> We currently have quite a lot of deep dependencies (widget A depends on
> widget B which depends on widget C, ...)
> Since that is the case, you'll see the top navigation pretty fast but it
> takes a while before a widget within a page is loaded.
> The suggestion would be to go to the deepest level and then render
> everything going up the tree.
> When that is finished, we could send everything in one request to the
> client.
> It would basically take server side template rendering to the next
> level.
> Some things we can do on the front-end to make it better (without server
> changes):
> (Warning - Some things on this list may hurt your feelings ^^ [1])
> Performance:
> 1) Use image sprites + don't allow other images on hover
> 2) Only use JavaScript when necessary
> We're currently using JavaScript for things we could be doing in
> CSS and abusing it for other things
> a) Hovers should be done in CSS
> b) Don't add click events & hovers to divs, only to anchor tags
> c) Don't add workarounds for bugs in the back-end
> d) Use CSS relative positioning instead of binding to the
> window.resize() and using global absolute positioning in JavaScript.
> e) Use CSS only dropdown menu's [2]
> 3) Remove all the polling - no setTimeout or setIntervals (also the
> ones in plug-ins)
> 4) Use tools like Speed Index [3], Speed tracer and YSlow
> Avoiding bugs:
> 1) Remove all the global variables
> Most of these are exposed by plug-ins that we use but some of
> them are ours.
> We shouldn't allow plug-ins that expose those and in our own
> code we should remove the ones that we have.
> 2) Remove the JSHint custom options
> 3) Remove unused legacy code (e.g. chat/unused api functions),
> images and CSS
> 4) Add more QUnit tests
> 5) Run QUnit tests on every commit - the long anticipated test
> server
> 6) Keeping it DRY - never! allow any copy/pasting going on (neither
> in CSS/JavaScript or HTML) - e.g. the error pages (jsp/html versions)
> 7) Extend the current API - provide functions like `isUrl` which is
> used by several widgets
> 8) Don't use plug-ins that use document.write or do external
> requests (e.g. addthis plug-in)
> Accessibility:
> 1) For every :hover, we should have a :focus (CSS)
> 2) As mentioned in the performance section, no JavaScript hovers (if
> it's a design need, we need to redesign) -> for instance activity
> buttons only showing on hover
> 3) Provide a drop target area
> Feel free to agree/disagree and to add your own thoughts and items.
> -- Christian
> [1] [1]http://www.flickr.com/photos/codepo8/2051752263/
> [2] [2]http://www.cssplay.co.uk/menus/new-dropdown.html
>
> [3] [3]https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
> _______________________________________________
> oae-dev mailing list
> [4][email protected]
> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>
> References
>
> Visible links
> 1. http://www.flickr.com/photos/codepo8/2051752263/
> 2. http://www.cssplay.co.uk/menus/new-dropdown.html
> 3.
> https://sites.google.com/a/webpagetest.org/docs/using-webpagetest/metrics/speed-index
> 4. mailto:[email protected]
> _______________________________________________
> oae-dev mailing list
> [email protected]
> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
--
D. Stuart Freeman
Georgia Institute of Technology
signature.asc
Description: Digital signature
_______________________________________________ oae-dev mailing list [email protected] http://collab.sakaiproject.org/mailman/listinfo/oae-dev
