Hey Eli, thanks for going through this. I added my responses inline.
Do you also have suggestions/feedback/opinions on the performance related
issues?
Thanks,
- Bert
On 17 Apr 2012, at 17:33, Eli Cochran wrote:
> +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.
Agreed, with issue 3 in mind.
> - No click events on divs (should be button/anchor elements)
Agreed, part of our review process is to filter these out.
> - Use relative positioning where possible.
Absolutely.
>
> 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.
It does and I don't think otherwise, I added all his suggestions in my
consolidated list to start up a discussion. What's your take on improving
accessibility?
>
> 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.
Agreed, we're switching over to that style of formatting gradually. SASS would
be a good move to make at some point, it's proven to be very efficient in the
widget library.
>
> 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.
This is already part of what we check for when reviewing code and why I
suggested using more central templates throughout the system.
>
> 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
_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
