×
Namespaces

Variants
Actions
(Difference between revisions)

View usability

From Nokia Developer Wiki
Jump to: navigation, search
Rahulsingh1m (Talk | contribs)
hamishwillee (Talk | contribs)
m (Text replace - "Category:Mobile Design" to "")
 
(7 intermediate revisions by 4 users not shown)
Line 1: Line 1:
[[Category:Mobile_Design]][[Category:Usability]]
+
{{ArticleMetaData <!-- v1.2 -->
 +
|sourcecode= <!-- Link to example source code e.g. [[Media:The Code Example ZIP.zip]] -->
 +
|installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 +
|devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Qt SDK 1.1.4]) -->
 +
|platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 +
|devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 +
|dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
 +
|signing= <!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20090623
 +
|author= [[User:Naresh99]]
 +
}}
 +
 
 +
[[Category:Usability]]
  
  
 
==Descriptions==
 
==Descriptions==
  
It is posible in Symbian Os, to define multiple views for a single application, and switch between views. An application can present data or content of application to the user in different views. Each view has its own identifier & application can switch between views according to the user actions. Best use of View is to use in Applicatoin which has complex form navigation path. To show multiple forms categorywise. For example, Application can show user personal data (name, surname, age) in one form. User's profession details(company name, designation) in another view.
+
A view is the basic building block of any application, and is the first thing that the user sees/possibly interacts with. It is important to carefully design the views of the application, both from a functionality and ease of use stand-point. The user should be able to use the application pretty much on his own without having to read the help manual or other instructions. At least the key functionalities of the application should be easily understandable and usable. Hence it is imperative to design the views of the application in such a way that the important featues/functionaltiies are available from the main view, while the lesser used features/information/setting etc can be done from the secondary views.
  
==Some usability guideline for view are==
+
Depending upon the usage pattern and functionality one should decide the overall look and feel, styling of the view.
  
* Application must handle view switching.
 
* It will provide you calling methods when to activate or deactive view.
 
* allow you to save view data.
 
* you can send data to other appliation's views also such as URL to a web browser.
 
* You can easily change your view classes & easily add new views.
 
* view can define as a class that has all the responsibility of displaying content.
 
<br><br>
 
'''Some view examples are'''
 
<br>
 
 
<table>
 
<table>
 
<tr>
 
<tr>
 
     <td align="left">
 
     <td align="left">
'''view example'''<br>               
+
'''Fly in-out view'''<br>               
[[Image:view1.jpg]]
+
[[File:Fly in view.JPG]]
 
   </td>
 
   </td>
 
     <td align="left">
 
     <td align="left">
'''view example'''<br>
+
'''Grid Style View'''<br>
[[Image:view2.jpg]]  
+
[[File:Grid style view.JPG]]  
 
     </td>
 
     </td>
  <td align="left">
+
</tr>
'''view example'''<br>
+
</table>
[[Image:view3.jpg]]  
+
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''List View'''<br>             
 +
[[File:List view.JPG]]
 +
  </td>
 +
  <td align="left">
 +
'''Tabbed View'''<br>
 +
[[File:Tabbed view.JPG]]  
 
     </td>
 
     </td>
 
   </tr>
 
   </tr>
</table>  
+
</table>
 +
 
 
<table>
 
<table>
 
<tr>
 
<tr>
 
     <td align="left">
 
     <td align="left">
'''view example'''<br>               
+
'''Detailed View'''<br>
[[Image:view4.jpg]]
+
[[File:Detail view.JPG]]
 +
    </td>
 +
    <td align="left">
 +
'''Setting View'''<br>
 +
[[File:Setting view.JPG]]
 +
    </td>
 +
  </tr>
 +
</table>
 +
 
 +
Sometimes it might be needed to use the full screen of the device to display a splash screen/progress etc. In those cases it is imperative to ensure that the view still follows the basic conventions. Even if the view doesn’t use the soft keys, the images should correspond to them, to allow user to navigate back/forward to other views.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
[[File:Splash screen.JPG]]
 +
  </td>
 +
  </tr>
 +
</table>
 +
 
 +
More details can be had from [http://library.developer.nokia.com/index.jsp?topic=/Design_and_User_Experience_Library/GUID-BCC29784-328E-46E2-AB5F-2763F169D062.html Full-screen usage on Developer Library]
 +
 
 +
It is possible in Symbian OS, to define multiple views for a single application, and switch between views. An application can present data/content of application to the user in different views after grouping them logically and in order of usage from most used to least used.
 +
 
 +
Each view has its own identifier & application can switch between views according to the user actions. Best use of view is to use in application which has complex form navigation path, i.e. to show multiple forms category wise. For example, Application can show user personal data (name, surname, age) in one form, user's profession details (company name, designation) in another view and so on.
 +
 
 +
==Some usability guideline for view are==
 +
 
 +
* '''Application must handle view switching'''<br>
 +
 
 +
 
 +
User should be able to easily make out what all views they can possibly navigate to, and what are the content/action they can possibly expect on those views. In case of settings etc, provide grouped option menu to take user to the setting view.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Ungrouped menu, takes more space on main menu'''<br>               
 +
[[File:Ungrouped options.jpg]]
 
   </td>
 
   </td>
 
     <td align="left">
 
     <td align="left">
'''view example'''<br>
+
'''Grouped menu, less space on main menu'''<br>
[[Image:view31.jpg]]  
+
[[File:Grouped options.jpg]]  
 
     </td>
 
     </td>
 
   </tr>
 
   </tr>
Line 47: Line 107:
  
  
* You can also switch to an external application view,such as browser or calender. Also application can pass parameters to them.Switching between to views requires a lot of thought and code to control everything that must be changed, updated, saved and drawn.  
+
* '''Should allow users to save view data'''<br>
 +
 
 +
 
 +
In case you are implementing text entry forms/settings view etc. if the user has changed any values, the back key should ask the user if they want to save the data before navigating out of the view.
 +
 
 +
<table>
 +
<tr>
 +
    <td align="left">
 +
'''Back Choice given'''<br>
 +
[[File:Form3Good.JPG]]
 +
    </td>
 +
  </tr>
 +
</table>
 +
 
 +
 
 +
* '''Addition/deleting of secondary views should be easy'''<br>
 +
 
 +
 
 +
Addition/deleting of secondary views should not alter the layout/flow of the main view by a great deal. The main view is the core of the application with which the user is familiar, in case of updates/changes to the application; make sure that the main view remains intact to a large extent. For instance if you are providing certain functionalities on the secondary view which can be enabled/disabled based on the license/trial period kind of model, the change should be seamless.
 +
 +
* '''View has all responsibility of the content it displays'''<br>
 +
 
 +
 
 +
From usability stand point it makes a lot of sense to let the view handle the data/content it is displaying to the user. The edit rules/option menu hiding etc should be done by the view. This helps from a maintainability aspect as well by water tightening the data integrity.
 +
 
 +
* '''Should handle events/commands passed by the view controllers'''<br>
 +
 
 +
The view should handle the events/commands passed by the framework. In case the view is not interested in those events, it should pass them back to the framework so that it can be handled properly.
 +
 
 +
* '''Option menu/soft key handling'''<br>
 +
 
 +
 
 +
View should provide the right options and soft key options to the user, which are consistent throughout the application and are easily usable and understandable. More details can be had from [[Options menu Usability]]
 +
 
 +
==Other functionalities supported by views==
 +
 
 +
* You can also switch to an external application view, such as browser or calendar. Also application can pass parameters to them. Switching between views alters the normal flow of events/interaction. Hence a lot of thought should be placed on their usage, how the content will be updated, saved and drawn etc.
 +
 
 +
 
 +
More details from:-
 +
 
 +
 
 +
[http://developer.sonyericsson.com/wportal/devworld/page-not-found?cc=gb&lc=en Dynamic Navigation Links in Symbian]
 +
 
 +
[http://www.developer.nokia.com/info/sw.nokia.com/id/fb030d76-e5f5-4a1d-ba7e-7d425ac8dd05/Utilizing_External_App_Views_v1_0.pdf.html Utilizing external application views]
 +
 
 +
It is also possible to add features dynamically to an application without linking to the code. Details from <u>[[Application Interworking(AIW)]]</u>
 +
 
 +
==View implementation on Symbian==
 +
 
 +
To create views derive it from CCoeControl class for displaying data and it should be derived from an interface class called MCoeView to create view. MCoeView interface has virtual functions which should be called by the view architecture to register a view, to get its identifier and switch from one view to another. Developer has to remove view from event stack & has to destroy them in destructor.
 +
 
 +
 
 +
More details from :-
 +
 
 +
[[S60 application views]]
 +
 
 +
[[S60 View Architecture with UI Design]]
  
* To create a view we still have to derive it from CCoeControl class for displaying data and it should be derived from an interface class called MCoeView to create view. MCoeView interface has virtual functions which should be called by the view architecture to register a view, to get its identifier and switch from one view to another. Developer has to remvoe view from event stack & has to destroy them in destructor.
+
[[How to work with views and view architecture]]
  
 +
[[View Vs Container]]
  
[http://wiki.forum.nokia.com/index.php/S60_application_views Click here for more details on S60 application views]
+
<b>--- Edited by Mayank on 26/06/2009 ---</b>

Latest revision as of 06:42, 9 May 2012

Article Metadata
Article
Created: naresh99 (23 Jun 2009)
Last edited: hamishwillee (09 May 2012)


Contents

[edit] Descriptions

A view is the basic building block of any application, and is the first thing that the user sees/possibly interacts with. It is important to carefully design the views of the application, both from a functionality and ease of use stand-point. The user should be able to use the application pretty much on his own without having to read the help manual or other instructions. At least the key functionalities of the application should be easily understandable and usable. Hence it is imperative to design the views of the application in such a way that the important featues/functionaltiies are available from the main view, while the lesser used features/information/setting etc can be done from the secondary views.

Depending upon the usage pattern and functionality one should decide the overall look and feel, styling of the view.

Fly in-out view
Fly in view.JPG

Grid Style View
Grid style view.JPG

List View
List view.JPG

Tabbed View
Tabbed view.JPG

Detailed View
Detail view.JPG

Setting View
Setting view.JPG

Sometimes it might be needed to use the full screen of the device to display a splash screen/progress etc. In those cases it is imperative to ensure that the view still follows the basic conventions. Even if the view doesn’t use the soft keys, the images should correspond to them, to allow user to navigate back/forward to other views.

Splash screen.JPG

More details can be had from Full-screen usage on Developer Library

It is possible in Symbian OS, to define multiple views for a single application, and switch between views. An application can present data/content of application to the user in different views after grouping them logically and in order of usage from most used to least used.

Each view has its own identifier & application can switch between views according to the user actions. Best use of view is to use in application which has complex form navigation path, i.e. to show multiple forms category wise. For example, Application can show user personal data (name, surname, age) in one form, user's profession details (company name, designation) in another view and so on.

[edit] Some usability guideline for view are

  • Application must handle view switching


User should be able to easily make out what all views they can possibly navigate to, and what are the content/action they can possibly expect on those views. In case of settings etc, provide grouped option menu to take user to the setting view.

Ungrouped menu, takes more space on main menu
Ungrouped options.jpg

Grouped menu, less space on main menu
Grouped options.jpg


  • Should allow users to save view data


In case you are implementing text entry forms/settings view etc. if the user has changed any values, the back key should ask the user if they want to save the data before navigating out of the view.

Back Choice given
Form3Good.JPG


  • Addition/deleting of secondary views should be easy


Addition/deleting of secondary views should not alter the layout/flow of the main view by a great deal. The main view is the core of the application with which the user is familiar, in case of updates/changes to the application; make sure that the main view remains intact to a large extent. For instance if you are providing certain functionalities on the secondary view which can be enabled/disabled based on the license/trial period kind of model, the change should be seamless.

  • View has all responsibility of the content it displays


From usability stand point it makes a lot of sense to let the view handle the data/content it is displaying to the user. The edit rules/option menu hiding etc should be done by the view. This helps from a maintainability aspect as well by water tightening the data integrity.

  • Should handle events/commands passed by the view controllers

The view should handle the events/commands passed by the framework. In case the view is not interested in those events, it should pass them back to the framework so that it can be handled properly.

  • Option menu/soft key handling


View should provide the right options and soft key options to the user, which are consistent throughout the application and are easily usable and understandable. More details can be had from Options menu Usability

[edit] Other functionalities supported by views

  • You can also switch to an external application view, such as browser or calendar. Also application can pass parameters to them. Switching between views alters the normal flow of events/interaction. Hence a lot of thought should be placed on their usage, how the content will be updated, saved and drawn etc.


More details from:-


Dynamic Navigation Links in Symbian

Utilizing external application views

It is also possible to add features dynamically to an application without linking to the code. Details from Application Interworking(AIW)

[edit] View implementation on Symbian

To create views derive it from CCoeControl class for displaying data and it should be derived from an interface class called MCoeView to create view. MCoeView interface has virtual functions which should be called by the view architecture to register a view, to get its identifier and switch from one view to another. Developer has to remove view from event stack & has to destroy them in destructor.


More details from :-

S60 application views

S60 View Architecture with UI Design

How to work with views and view architecture

View Vs Container

--- Edited by Mayank on 26/06/2009 ---

This page was last modified on 9 May 2012, at 06:42.
156 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×