Roadmap: Framework v1.3
The next planned release version of the mobile web framework will include several new features:
- Forms UI and Javascript Libraries
- Messages UI
- Customizable Home Page / "App Store"
- Javascript Unit Tests
- Javascript Decorators
- Javascript Interactivity Libraries
- Javascript Preferences
- Javascript-based Handlers
- Lean CSS Markup Entities
- Basic Native Container
Primary: Ike Lin (UCLA) Secondary: Eric Bollens (UCLA)
The specification for Forms 1.3 is available here.
Primary: Ike Lin (UCLA) Secondary: Eric Bollens (UCLA)
The specification for Messages 1.3 available here.
The current front page for the Mobile Web Framework supports a main menu and submenus, but it lacks support for deeper organization and personalization. This rewrite of the front page will change underlying application logic and add several new features:
- User personalization of the menus
- Hierarchical organization of the menus.
- Two layouts (list or icon) with user customizability.
-
App store functionality to add apps not in the default layout.
The front page will support three types of entities: modules, module categories and module directories. Module categories are pre-defined clusters of modules like “Campus Life”, “Student Tools” and “Library Resources”, while module directories are user-defined sets of applications like folders in iOS. The display will also support organization in both list and icon style.
By default, new visitors are presented with a set of modules and module categories in a similar form to the current home page. An administrative interface will allow for configuration of this default set as well as its presentation as a list or icon style.
When logged in, a user will be able to use a set of touches and gestures to customize the home page (similar to the iPhone home screen). They will be able to select modules and module categories, as well as to create their own module directories, adding the modules and module categories they want into such directories.
All visitors and users will also be able to use a search function to find particular modules and module categories. For visitors, this allows them to access the modules, and for authenticated users it will also allow them to search to add items to their personalized home page.
Primary: Richard Trott (UCSF) Secondary: Eric Bollens (UCLA)
Qunit tests for JavaScript will help insure that code changes do not introduce (or re-introduce) unexpected behavior or other bugs. This will also allow contributors to refactor code with more confidence.
Primary: Zorayr Khalapyan (UCLA) Secondary: Eric Bollens (UCLA)
A set of Javascript objects capable of producing MWF markup in a similar style to the PHP decorators.
Just like PHP decorators simplified the development of mobile interface design on the server side, Javascript based decorators will aim to simplify UI design on the client side. Developers utilizing the JS decorators library will be abstracted from the schematic CSS classes or the structure that MWF requires for creating menus, content, buttons, and various other MWF entities.
JS code for each HTML/CSS entity will be isolated in separate files (i.e. menu.js) and later combined and minified, if necessary, upon request. For efficiency, request can include all or only support for individual entities.
Please see API: JS: Decorators page for more details on the capabilities of the JavaScript based decorators.
Primary: Eric Bollens (UCLA)
The specification for JS Interactivity 1.3 available here.
Primary: Rich Trott (UCSF)
A simple JS API will allow content providers to set and read preferences for a user's device.
Primary: Eric Bollens (UCLA) Secondary: Zorayr Khalapyan (UCLA)
While the MWF includes PHP-based handlers, given that all logic concerning capabilities, classifications, user agents and dimensions is determined by the Javascript-driven device telemetry stack, it is possible to leverage pure Javascript to load in CSS and Javascript libraries as needed. These handlers will provide all the same functionality as the PHP handlers, and they will attempt to mirror the implementation as much as possible to minimize maintenance challenges.
The objectives of this are as follows:
- Use of the MWF in a purely local context (such as a native application with all content stored locally).
- Portability to environments where PHP is not an option.
At this point in time, these are not viewed as a replacement for the PHP handlers, but rather an additional interface where useful. Care will need to go into implementation to ensure that they will work acceptably in non-Javascript environments.
Primary: Eric Bollens (UCLA) Secondary: Ike Lin (UCSD) & Rich Trott (UCSF)
The current CSS markup entities have slightly redundant definitions. For example, .content-full.content-padded could be better expressed as .content.padded. This will serve two purposes: (1) reduce the size and complexity of the CSS file (long term), both by reducing the number of definitions (as padded is a similar behavior between all implementations), and (2) reduce the size and complexity of the HTML that leverages the framework.
This will be accomplished by providing a new lean option in the CSS handler for MWF 1.3+ and then by removing the verbose markup in MWF 2, or alternating the default behavior to use lean and adding a compat flag. An alternate proposal suggested providing a compat flag that allows the user to request markup from a previous version, but this will add a layer of complexity without major benefit, and thus it has been foregone from this feature for MWF 1.3, at least at this time.
Providing the lean option let's content providers leveraging MWF 1.3 entities to minimize the size of their stylesheet, while still providing backwards compatibility for content providers that are still using the old CSS markup entities.
Primary: Zorayr Khalapyan (UCLA)
Description coming soon...