Bug 970523

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

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.

(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.

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.

AFAIU engine-devel, this is still on long-term radar so let's keep it open.

(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.)

Closing old bugs. If this issue is still relevant/important in current version, please re-open the bug.