Itamar, I'm actually looking forward to the portal and web admin next week. I'm certain there will be some convergence/reusability there and it would be helpful to see the different use cases at hand. I'm also looking at ways to ensure As a background, we used the RHEVM-API because of it provides us the ability to do pretty much anything that the IE-Only GUI did. And with fewer clicks ;-) Before that, my alternative was to fire up my Remote Desktop application on my Xoom and pull back the windows environment - not very android wifi friendly. I think there are 2 design goals that are relevant here: 1) One codebase to generate a mobile application for both iOS and Android. 2) Cache the immutable attributes for resources (GUIDs, in particular) to the number of remote calls. This does not preclude someone from flipping to the full browser on the mobile device, but it can provide some quick admin functionality, especially in when there is a poor network connection. Isaac On 10/27/11 2:10 PM, Itamar Heim wrote:
sorry i am late to this, but workshop preparations took their toll this week.
unlike rhev-m 2.2 which required a windows client, ovirt has a full web admin based on GWT (which should work on tablets as well)
I do see a place for a UI designed more for smartphones. I am not sure if technology (and effort) wise it will be better to develop it separately over the REST API, or improve the ovirt web admin and user portal to render/look better for smaller screens.
I want to be clear i am not against Nomad, but i recommend Nomad to review the web admin and user portal ovirt has to see if a "smartphone/tablet" mode for it wouldn't be much easier to do.
for example, the user portal and web admin share the same "UI Common" logic code for the parts shared for them.
maybe creating another view layer on top of the same UI logic (rather than on the REST API) would make more sense.
I'd also check if tablets are still an issue with the web admin - apart from maybe adjusting to a little bit lower resolution, it should work as is.
I think understanding if/how the flows and look and feel are different for this use case would be important to understand this.
would love to see some discussion on this next week.
Thanks, Itamar
On 10/24/2011 03:11 PM, Carl Trieloff wrote:
This vote is to include Nomad into the oVirt incubtaor. Details about the project can be found at http://www.ovirt.org/wiki/Project_Proposal_-_Nomad
More information about the incubator at oVirt can be found at http://www.ovirt.org/governance/adding-a-subproject/
In order to be accepted into the incubator, the project needs to be able to articulate its goals, scope and how it relates/integrates with the oVirt project. Nomad has done this. Entering the incubator is the low bar vote, which Nomad in my view clearly gets over.
Note that the vote from incubator to full oVirt project (not this vote) is where we look for the demonstration of project criteria. The idea with the incubator is that any project that can articulate how it relates to oVirt should be able to enter the incubator and then work out details while in incubation.
Vote open till the 27th.
Here is my +1
Carl. _______________________________________________ Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
Board mailing list Board@ovirt.org http://lists.ovirt.org/mailman/listinfo/board
-- Isaac Christoffersen Sr. Software Engineer, Vizuri web: http://www.vizuri.com -- "Tell me and I forget. Teach me and I remember. Involve me and I learn." - Benjamin Franklin