Bug 970523 - [RFE] provide version of (a subset of) webadmin functionality usable on small form-factor touchscreens
[RFE] provide version of (a subset of) webadmin functionality usable on small...
Status: CLOSED WONTFIX
Product: oVirt
Classification: Community
Component: ovirt-engine-webadmin (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Nobody's working on this, feel free to take it
bugs@ovirt.org
ux
: FutureFeature, Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-04 04:55 EDT by David Jaša
Modified: 2014-06-16 11:40 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-16 11:40:35 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2013-06-04 04:55:53 EDT
Description of problem:
RFE: provide version of (a subset of) webadmin functionality usable on small form-factor touchscreens.

There are situations when a smartphone is the only readily-available device with a web browser and ability to really use it for control of oVirt environment can save a lot of headaches (or journey to get "a real computer"). Current webadmin doesn't make the cut because:
1) there are far too many visual elements on the page, once the page is zoomed, intra-page navigation is extremely hard
2) usability of some of the elements and concepts on touchscreen is hard (try to select more VMs at once or hit some of the minuscule action elements on top of the lists)

I don't think that general "schema" of the UI would have to be really different, it could still form the current abstract tree:
(root)
- search/logout/configure
- tree view + main tabs
-- item list 
--- sub tabs
---- each sub tab
- runtime info
-- log
-- ...
but each node in the tree has to have whole screen for itself - e.g. once you hit the VM, you should be taken from VM list to VM actions and sub tab list where you could either choose a particular action/subtab or dismiss action/subtab list and return to VM list.

There is a caveat though: screen resolution is not a good metric to base decision on portal version to present to the client high-end 5" smartphones already feature 1920x1080 resolution.

Version-Release number of selected component (if applicable):
3.3

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 1 vszocs 2013-06-18 06:13:02 EDT
First, we should create some UI mock-ups and get them approved by people familiar with UI design and usability with regard to mobile devices.

Having the mock-ups, we can decide on how to implement the mobile version, I see two options here:

a, use existing WebAdmin (GWT) code-base, implement "mobile" Views that would replace "standard" Views based on device detection
b, use Backbone/jQuery/etc. (JavaScript) libraries to implement mobile version, utilize Engine REST API for communication
Comment 2 Alissa 2013-06-19 06:40:14 EDT
I think that a general conceptual problem would be accessibility. If we want to publish a mobile app, it still needs to "talk" to the engine. That means that engine needs to be exposed outside of the organization, otherwise what benefit does the mobile app give if it works only when the user is at work? They have the desktop there, so it becomes not interesting. Not sure that many customers would be able to (due to security issues) expose it outside of lan - perhaps PMs have that info?

Regardless of that, I am not sure that porting webadmin as a configuration management tool (add/delete/edit entities) is the right way to go, considering the size of small touchscreens. The amount of things that need to be done in order to configure an entity in ovirt is big. So if mobile app will become just a bunch of wizard screens to configure there things, I think it will be a pain to use it. Perhaps giving some limited functionality such as activate host/put storage to maintenance - that will benefit the users. Otherwise, why would a user want to configure a big complicated system from a tiny screen?

In other words, I think the first question that needs to be asked is "which oVirt scenarios are relevant for mobile, and when user would like to do them on the go with his phone when he has no desktop around" ? I think that most of the work will be when someone is on call and needs to "extinguish fire", rather than start configuring the system.
Comment 3 David Jaša 2013-06-19 16:14:33 EDT
(In reply to Alissa from comment #2)
> I think that a general conceptual problem would be accessibility. If we want
> to publish a mobile app, it still needs to "talk" to the engine. That means
> that engine needs to be exposed outside of the organization, otherwise what
> benefit does the mobile app give if it works only when the user is at work?

Cell phones capable to run recent web apps are capable to connect to VPNs or WPA Enterprise wifis as well.

> They have the desktop there, so it becomes not interesting.

It is once you are in a lab when you realize that you need to touch some aspect of running RHEV and your laptop is on your workplace minutes of walk away

> Not sure that
> many customers would be able to (due to security issues) expose it outside
> of lan - perhaps PMs have that info?
> 
> Regardless of that, I am not sure that porting webadmin as a configuration
> management tool (add/delete/edit entities) is the right way to go,
> considering the size of small touchscreens. The amount of things that need
> to be done in order to configure an entity in ovirt is big. 

That applies just to iscsi storage configuration IMO. Pretty much any other configuration is already broken down to tabs whose content is of right size for small screen (just if tabbed paradigm is replaced with hub-and-spoke paradigm).

> So if mobile app
> will become just a bunch of wizard screens to configure there things, I
> think it will be a pain to use it. Perhaps giving some limited functionality
> such as activate host/put storage to maintenance - that will benefit the
> users. 

Add all things that repeatedly block host transition to maintenance state and you'll end up with something that can accomodate all the current admin portal functionality.

> Otherwise, why would a user want to configure a big complicated
> system from a tiny screen?
> 
> In other words, I think the first question that needs to be asked is "which
> oVirt scenarios are relevant for mobile, and when user would like to do them
> on the go with his phone when he has no desktop around" ? I think that most
> of the work will be when someone is on call and needs to "extinguish fire",
> rather than start configuring the system.

Yes, that is my intention, too. If the UI is brand new (Vojtech's option b), then it is certainly good to start with most needed functionality first and evaluate if further additions are necessary. OTOH if current UI is reused and it is feasible to have two presentations of the same logical UI structure, then exposing full functionality shouldn't do any harm.
Comment 4 Itamar Heim 2013-12-01 03:59:15 EST
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.
Comment 5 David Jaša 2013-12-02 06:11:43 EST
AFAIU engine-devel, this is still on long-term radar so let's keep it open.
Comment 6 vszocs 2013-12-09 08:45:54 EST
(In reply to David Jaša from comment #5)
> AFAIU engine-devel, this is still on long-term radar so let's keep it open.

+1

This should play well together with oVirt JavaScript SDK initiative, i.e. talking to Engine should be easy once we have some JavaScript SDK to work with.

> In other words, I think the first question that needs to be asked is "which
> oVirt scenarios are relevant for mobile, and when user would like to do them
> on the go with his phone when he has no desktop around"

Fully agreed.

(In comment #1 I proposed UI mock-ups, which should be done only after analyzing relevant usage scenarios.)
Comment 7 Itamar Heim 2014-06-16 11:40:35 EDT
Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

Note You need to log in before you can comment on or make changes to this bug.