+1 to the entire list.
I'd like to suggest two changes, one substantive, the other an edit.
The edit: break "Avoid using JavaScript in places like hovers, click events on
divs (should be button/anchor elements) and use relative positioning where
possible." into three issues:
- Avoid using JavaScript in places like hovers.
- No click events on divs (should be button/anchor elements)
- Use relative positioning where possible.
These are all separate and unrelated suggestions.
More substantive: please bring back Christian's list of accessibility
suggestions. These should be lost. Accessibility deserves more than just a one
liner.
More:
Before we go with something like SASS, we need to clean up the CSS. I think
that the big win for SASS will be for skinning which right now is mired in
!important hell, especially for widgets.
Current single line CSS formatting is silly, that's what magnification is for.
The only thing that it does is make it hard to read.
I think that there is more to explored with unit testing of front-end code. My
totally half-baked suggestions are either much more exposure of internal
methods or test blocks that could be automatically removed during deployment.
Grunt might be useful here for automated JS unit testing on the server -- for
running tests, not writing tests; still a fan of qunit.
Reuse, reuse, reuse. No copy and paste. You could bring this back from
Christian's list as well.
Let's get this list into confluence somewhere.
Thanks,
Eli
On Apr 17, 2012, at 4:00 AM, 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.
>
> - 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
. . . . . . . . . . . . . . . . . .
.
Eli Cochran
project manager, CalCentral project
Educational Technology Services, UC Berkeley
"Do not solve the problem that’s asked of you. It’s almost always the wrong
problem."
- Don Norman
_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
