Difference between revisions of "WebIssues/Web and Mobile Interfaces"

From MiMec
Jump to: navigation, search
(New page: This is a brief introduction of some proposals for the fifth stage of development: Web Interface and Mobile Interface. The page describing the rich Web Client can be found [[../Web Client...)
 
Line 1: Line 1:
 
This is a brief introduction of some proposals for the fifth stage of development: Web Interface and Mobile Interface.
 
This is a brief introduction of some proposals for the fifth stage of development: Web Interface and Mobile Interface.
  
The page describing the rich Web Client can be found [[../Web Client|here]].
+
== Introduction ==
 +
 
 +
With the completion of the [[../Roadmap#Stage 4|forth stage]] of development, both the server and the desktop client will be mature and feature rich. The next step is to provide alternative ways of accessing and using WebIssusues by creating so called ''interfaces''. An interface is an application which provides only the most important functions of WebIssues (that is: searching, displaying and modifying issues) for an alternative environment, such as web browser and mobile devices.
 +
 
 +
Although initially there were plans to provide a rich [[../Web Client|Web Client]] which would provide similar functionality to the desktop client, these plans failed because of huge amount of work required and limited manpower. Now I think that providing an exact equivalent of the desktop application is neither possible nor necessary. Instead a different approach will be taken: allowing to use WebIssues virtually everywhere.
 +
 
 +
So basically using the desktop client would still be the preferred way of using WebIssues, and the only way to perform administrative tasks and other complex tasks such as generating reports. However for simply accessing information and performing basic operations, the interfaces could be used if using the desktop client is not possible for various reasons.
 +
 
 +
=== Web Interface ===
 +
 
 +
The WebIssues Web Interface is a web application written in PHP, which connects directly to the WebIssues database using a similar database abstraction layer as the server. It does not communicate with the server and does not use the WebIssues protocol, it doesn't even have to be installed on the same physical machine as the server. It provides its own mechanisms of filtering and listing the issues, listing issue details, etc., which in some way is very similar to the client, except that most data is fetched directly from the SQL database and not from the in-memory database.
 +
 
 +
The application should be as simple and light-weight as possible. It should not use AJAX and ideally should work without JavaScript, although JavaScript can be used sparingly to improve the look and feel and the functionality of the application. It also doesn't need to resemble the desktop client in every aspect, but rather should be designed from scratch for maximum usability in web environment.
 +
 
 +
Probably the biggest challenge in designing the web interface is implementing filters, without which the usability of the application would be very limited. Filters in the desktop client are quite flexible and powerful and their functionality would have to be ported to the web interface. Another problem is that filters are currently stored locally in the client's configuration file. To be really usable, they need to be shared between the desktop client and the interfaces. A very useful feature would be to have both system-level filters (defined by the administrator) and user-level filters (defined by individual users).
 +
 
 +
Another useful feature would be the ability to use WebIssues as a guest user, which doesn't have to log in and has read-only access to some configurable parts of the system. That would allow, for example, to use WebIssues as a knowledge base which is available to everyone or for intranet users only.
 +
 
 +
The web interface should also be able to produce RSS feeds for both issues in a particular folder and for comments and other changes in a particular issue. That feature would be especially useful in connection with the guest user, although feeds requiring user authentication are also not uncommon.
 +
 
 +
=== Mobile Interface ===
 +
 
 +
The WebIssues Mobile Interface communicates with the WebIssues server and it basically works in the same way as the desktop client, storing all required data locally and implementing all the logic on its own. Different versions of the application can be available for tablet devices, pocket devices and even mobile phones (using Qt for Windows CE and the version for Symbian which is [http://trolltech.com/about/news/qt-for-s60-announced coming soon] would make this possible). That would open another huge range of possibilities in using WebIssues.
 +
 
 +
Obviously the mobile interface would need to provide a very simplified user interface, designed to be usable on mobile devices. Also some considerations for limiting memory usage and network usage should be taken. Visually and functionally the mobile interface would resemble the web interface much more than the desktop client, that's why these two projects are described together. Also the need for sharing filters and other settings is a common requirement of both interfaces.

Revision as of 17:21, 3 November 2008

This is a brief introduction of some proposals for the fifth stage of development: Web Interface and Mobile Interface.

Introduction

With the completion of the forth stage of development, both the server and the desktop client will be mature and feature rich. The next step is to provide alternative ways of accessing and using WebIssusues by creating so called interfaces. An interface is an application which provides only the most important functions of WebIssues (that is: searching, displaying and modifying issues) for an alternative environment, such as web browser and mobile devices.

Although initially there were plans to provide a rich Web Client which would provide similar functionality to the desktop client, these plans failed because of huge amount of work required and limited manpower. Now I think that providing an exact equivalent of the desktop application is neither possible nor necessary. Instead a different approach will be taken: allowing to use WebIssues virtually everywhere.

So basically using the desktop client would still be the preferred way of using WebIssues, and the only way to perform administrative tasks and other complex tasks such as generating reports. However for simply accessing information and performing basic operations, the interfaces could be used if using the desktop client is not possible for various reasons.

Web Interface

The WebIssues Web Interface is a web application written in PHP, which connects directly to the WebIssues database using a similar database abstraction layer as the server. It does not communicate with the server and does not use the WebIssues protocol, it doesn't even have to be installed on the same physical machine as the server. It provides its own mechanisms of filtering and listing the issues, listing issue details, etc., which in some way is very similar to the client, except that most data is fetched directly from the SQL database and not from the in-memory database.

The application should be as simple and light-weight as possible. It should not use AJAX and ideally should work without JavaScript, although JavaScript can be used sparingly to improve the look and feel and the functionality of the application. It also doesn't need to resemble the desktop client in every aspect, but rather should be designed from scratch for maximum usability in web environment.

Probably the biggest challenge in designing the web interface is implementing filters, without which the usability of the application would be very limited. Filters in the desktop client are quite flexible and powerful and their functionality would have to be ported to the web interface. Another problem is that filters are currently stored locally in the client's configuration file. To be really usable, they need to be shared between the desktop client and the interfaces. A very useful feature would be to have both system-level filters (defined by the administrator) and user-level filters (defined by individual users).

Another useful feature would be the ability to use WebIssues as a guest user, which doesn't have to log in and has read-only access to some configurable parts of the system. That would allow, for example, to use WebIssues as a knowledge base which is available to everyone or for intranet users only.

The web interface should also be able to produce RSS feeds for both issues in a particular folder and for comments and other changes in a particular issue. That feature would be especially useful in connection with the guest user, although feeds requiring user authentication are also not uncommon.

Mobile Interface

The WebIssues Mobile Interface communicates with the WebIssues server and it basically works in the same way as the desktop client, storing all required data locally and implementing all the logic on its own. Different versions of the application can be available for tablet devices, pocket devices and even mobile phones (using Qt for Windows CE and the version for Symbian which is coming soon would make this possible). That would open another huge range of possibilities in using WebIssues.

Obviously the mobile interface would need to provide a very simplified user interface, designed to be usable on mobile devices. Also some considerations for limiting memory usage and network usage should be taken. Visually and functionally the mobile interface would resemble the web interface much more than the desktop client, that's why these two projects are described together. Also the need for sharing filters and other settings is a common requirement of both interfaces.