Community: Meeting Agendas and Notes: Developer's Meeting 2011 06 22

Campus Updates

Berkeley added a search bar to their mobile application. Defaults to the google site search.
When designing the search bar, noticed some issues with width based on device. What is the recommended way to specify fluid width for search fields on mobile?
(Eric) The best way to achieve this is to use a percentage width on the field in conjunction with a maximum width, so that the field will not grow unbounded for high width devices (iPads or other tablets).
Developer Reception at Berkeley was excellent after Eric's presentation two weeks ago. The general sentiment is that the framework takes care of the technical issues of device detection and mobile styling, but now the developers need to be educated on how to rethink mobile UI's. What is the best approach?
(Eric) We will discuss this point in the next MCG meeting, but we could write a wiki page with extended documentation for this process as well as links to additional resources regarding Mobile UI design.

UCLA Mobile is updating to MWF 1.1. A test instance is live at http://m.ucla.edu/dev so content providers can check their mobile application against MWF 1.1. Content providers are encouraged to test this deployment and contact Eric with any issues encountered.
Primary difference is device classifications. "Touch" is now "Standard", "Webkit" is now "Full", and "Basic" is still "Basic". The change is fully backwards compatible, so if you are using touch or touch_libs, they still map to standard_libs, but it is recommended that for future reference you update terminology to use these new classifications. More information on this and other changes in MWF 1.1 can be found in the release notes.

The conversion process to MWF 1.1 is fairly lightweight. The recommended process for upgrading is as follows:

Follow the git workflow to create a private branch of the MWF repository. Note: Be sure to switch to the latest tag of 1.1 before cloning the repository.
Edit configuration files as needed. The configuration files are stored in /config, and by default an institution only needs to edit global.php.
Create a campus-specific CSS directory in /root/assets/css. Within this directory, create three stylesheets for the three device classifications: basic.css, full.css, standard.css. Campus specific styles should be defined in these stylesheets.
If you added campus-specific style sheets in the previous step, be sure to specify your custom CSS directory in config/css.php. In the line Config::set('css', 'custom', false); one should change false to "{DIRECTORY_NAME}" based on what one named the directory with your custom stylesheets in the previous step.
The new PHP decorators enable one to replace all HTML code in the existing MWF app. If so desired, one can port all default modules to the decorators to minimize code and enable easier configuration.

Q. It has been said that departments they are not REQUIRED to cater to the lowest common denominator device. Is it acceptable to code for more robust devices? Specifically regarding AJAX functionality so pages don't need to reload.
A. You can always code in such a way that the code will work for the lowest common denominator. In the given example of loading additional page content on a click, the preferred method would be to provide links to additional pages by default, and then override the link functionality with javascript. One way to do this would be to attach a click event handler with jQuery that uses preventDefault() to prevent the actual link from being followed if the user has javascript installed.