IT-group

Apps Web Portal

A Rapid Apps Development proposal
26-06-2013

Proposition:
We propose a web base system to build native (iOS, Android) mobile apps. Involving the client in the complete process of generating and scheme for the application, this scheme will cover the natural flow of the application, being at the beginning a tab bar navigation system with a possible connection from the home page to a given section.

The Service:
The client will be present with website (including state of the art: HTML5, Java script and CSS3) where he will select in a dynamic way from a list of suggested features, the features will include: The platform Type of backend Color scheme Sections and types them Is important to notice that an important point in the construction of an app is the data the application can show, to maintain the capability of a RAD we have to set a basic data set for each section. Leaving to the user to submit the correct content for each section, the customization of the data for each section could be possible but still the client have to submit a complete set of data and a version of the desired data set. Finally the system needs to provide some kind of security to give the user the correct experience about the protection of the data he submits.

The Process:
The user will be present wit a set of forms (HTML5, CSS3), order in what we will call sections, where he will be given the key information needed to build a final product, the user will find the following sections: Platform: the user can select between the possible platforms starting iOS and possible Android. Backend: the possibilities for this section are: o No CMS: the data have to be provided by the client following some rules to be specified, this data will be included inside the apps, so is important to remark the fact that any change in the data will cause a new upload of the application. o CMS + WS: the data have to be submitted using a concrete format, we have to set the format, so we can set the content inside the WS and then maintain this service with our CMS. Color Scheme: the client will be presented with some preset color schemes, this
AWP 2

could be a good number of them, we have to consider that we will use the system objects these color schemes will have to change as we are starting with iOS6 and soon we will have to include iOS7. Sections: Starting with the home as a base section, the client can select the from a set of templates the form of each section, the client will be asked to select: o Name of section o Type of section: the client will select from a number of templates (see next section) o Data source: depending on the backend selection, the user will be asked for a source of the data to be displayed. o Share section: the client can select if he wants to share or not the details of the corresponding section, the client have to submit the content to be share. Notice: the data to be share needs to be fixed (not dynamic) we can set different data for each section but not dynamic. o Icon of the section: the client will be able to submit an icon for the section (in the correct format to be specified) or select from a set of icon provided by our system, the user can always choose from a set of default icon for the different kind of sections like: photo, news, video, events, music and catalog. This set of icons should be offer by the system as default. o The client will be able to add new sections where he will be asked all the previous questions.

For the client this process should be simple, the flow should not present any major problem for the client. We can even think on save the state of the request so the client can leave the process and retake it for submission when he have al the data needed, so we have to think in a internal user system to have a track of the process.

The Sections:
The sections can be divided by type (just for reference and guide to the client) some of the proposed section can be used for Multi-purpose, as the user can set the name of the section, other sections are more restrictive on their use because the data to be displayed (p.ej. photo section or video section). Photo Section: The photo section will have two possible templates to work with, the first template will be:

AWP

Displaying a table for albums, a view to display the content of the album finally a detail view (which may implement a swipe album). If the client want to display just one album, then the template will be

For configuration the client will have the following options: No CMS: Fix number of albums, each album with a fix number of photo (not possible to update without new submission) CMS + WS: no restriction Possible sources: o Instagram (by tag, by album, ...) o Other feeds (needs extra configuration depending on the API) o CMS Share: possible to share images, also can be shared a fix content. Video Section: The Video section will have two possible templates to work with, the first template will be:

Other possible view template is:

For
AWP

DE TA I LS

DE TA I

LS

configuration the client

4

will have the following options: No CMS: Fix number of albums, each album with a fix number of videos (not possible to update without new submission) CMS + WS: no restriction Possible sources: o YouTube (possible to include vimeo, but the API have to be included there will be integration in iOS7) o Other feeds (needs extra configuration depending on the API) o CMS (just to add YouTube links) Share: possible to share a fix content.

Events Section: The Event section will have two possible templates to work with, the first template will be:

Other possible view for events is:

For configuration the client will have the following options: No CMS: Fix number of events (not possible to update without new submission) CMS + WS: no restriction
AWP 5

DE TA I

LS

DE TA I LS

Data Restriction: the events should have an order, possible date order, but the order cant be variable, or the order have to be fix by the user. Share: possible to share a fix content.

List Section (Multi-porpoise section): This section will have two possible templates to work with, the first template will be:

The other possible view for a generic list is:

For configuration the client will have the following options: No CMS: Fix number elements (not possible to update without new submission) CMS + WS: no restriction Data Restriction: we will supply a number of elements to be displayed in the list, possible to chose between include photo or not, the ordering of the data will be the one given by the user. Share: possible to share a fix content. Catalog Section: The catalog section will have two possible templates to work with, the first template will be used for a catalog of n-level deep catalog:

DE TA I

LS

DE TA I LS

AWP

DE TA I LS

The other possible view for a generic list is:

Pop-up with categories categories

For configuration the client will have the following options: No CMS: Fix number elements (not possible to update without new submission) CMS + WS: no restriction Data Restriction: we will supply a number of elements to be displayed in the list, possible to chose between include photo or not, the ordering of the data will be the one given by the user. Share: possible to share a fix content. The last two section are very delicates respect to it content, specially in the case of no CMS.

Home Page (Multi-porpoise section): This section will have three possible templates to work with, the possible templates are:

TEXT

TEXT
AG E AG E

AG E

IM

IM

TEXT

BUTTON

AWP

IM

DE TA I

LS

The user should submit the corresponding data: images, text. The connection of the button should be indicated from the list of section defined for the application.

HTML View (Multi-porpoise section): This kind of section will have just one possible view, it requires am URL or some HTML text to be displayed, in the case of No CMS the content will be static and difficult to change.

AWP