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.
- 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
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] 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
> _______________________________________________
> oae-dev mailing list
> [email protected]
> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
