Hello Everybody, The #openstack-ux project specifically has been setup to help with user experience designs.
We use a tool called invision [0] for visual design commenting and interactions. In addition, The UX repo has been setup to help facilitate this process and Piet (the PTL) is looking Into OpenSource opportunities. [1] [0] https://openstack.invisionapp.com/d/main#/projects [1] >From Piet: MOCK REVIEW TOOLS There has been some discussion around replacing Invision because of the speed, not being open source, etc. I was hoping you could take a look at a couple of alternatives. To set expectations, it will need to be an open source project and be hosted by either the OpenStack Infrastructure project or a specific company. Phabricator Pholio http://phacility.com/phabricator/pholio/ Review board https://www.reviewboard.org/ Thanks, Travis On 3/15/16, 9:30 PM, "Soichi Shigeta" <shigeta.soi...@jp.fujitsu.com> wrote: > > Hi, > > Please find attached file. > Yet another design of the Network Topology Tab. > > # I couldn't upload pdf files to the Wiki. > When I tried, a message ".pdf file is not permitted" > was shown. > > Regards, > Soichi > >> >> Hi Anil, and folks, >> >> Thank you for your comments. >> >>> Thanks Soichi and Kaz for your work on implementing Horizon >>> (dashboard) support for TaaS. The proposal (with screen shots) >>> discussed in our recent IRC meeting look very nice. Here are some >>> additional suggestions for improvement. >>> >>> >>> >>> 1. General >>> >>> a. When a port is being selected (for a tap-service instance or >>> a tap-flow) it would be nice to also provide some extra information >>> associated with that port, such as the VM it belongs to and the IP >>> address. This will look very similar to what is being done today when >>> associating a floating IP with a VM vNIC. The extra context will allow >>> users to identify their source and destination end-points with more >>> ease. If a VM is not currently associated with a port then the extra >>> information is not necessary. >> >> I agree with you. >> It is difficult for users to select an appropriate port >> by seeing only uuid. >> >> I didn't explain in the submitted document, in the current >> implementation, not only uuid but also name is also shown >> if a port is given a name. >> >> I agree to show IP address. >> i.e., name, uuid, and IP address are shown for each port. >> Please refer p.1 of the attached file. >> >> On the other hand, in terms of modification cost, I'd like >> to disagree to show associated VM. >> Because Neutron doesn't know association between a port and >> a VM, we need to send a query to Nova. >> Of course, I agree to implement this if requested from field. >> >> >>> b. When selecting the traffic monitoring direction, it would be >>> nice to provide two check boxes, one for 'ingress' and the other for >>> 'egress'. A user wishing to monitor a port in both directions can >>> select both check boxes. I feel this looks better than having an >>> option called 'both'. >> >> In terms of consistency with the option in CLI, I prefer to >> chose one of the both/ingress/egress from pull down menu. >> >> To avoid confusions, it had better to say something like >> "ingress (to instance)" and "egress (from instance)". >> >> >>> 2. Using the Tap Services Tab >>> >>> a. Allow tap-flow-create and tap-flow-delete operations to also >>> be carried out from here. This will let users who prefer working in >>> this fashion get everything done from the same place. >> >> I will plan to add "tap-flow-create" and "tap-flow-delete" button >> on the tap-service tab. >> >> But, I'm afraid that a lot of ports will be listed as candidates >> when a user starts tap-flow-create from here. >> Because no instance (VM) is selected here, we can not filter to >> list. >> >> >>> b. Provide a way to list tap flows currently associated with a >>> tap service. >> >> Excuse me, I didn't mention about it on the submitted document. >> This is done on the overview of a tap-service. >> Please refer p.2 of the attached file. >> >> >>> c. Allow multiple tap-flows to be created at the same time. Let >>> the user pick multiple source ports (and traffic monitoring >>> directions) and have all of them attached to a designated tap-service. >> >> I'd like to consider this in the future. >> Because it seems taking larger man-hour cost to realize. >> (consideration with man-hour we have) >> Additionally, I think we need to take care of error cases >> such as a part of tap-flow creation failed. >> >> >>> 3. Using the Network Topology Tab >>> >>> a. Allow tap-create and tap-delete operations to be also carried >>> out from here. This will allow users who prefer working in this >>> fashion get everything done from the same place. The user can pick the >>> destination port (from one of the existing VMs) in the same way that a >>> source port is picked when creating a tap-flow. >> >> Yes, I think this is a good idea. >> I will plan to add "tap-flow-create" and "tap-flow-delete" buttons >> on the Network Topology tab. >> # As mentioned in 2-a., I'm afraid that a lot of ports will be >> listed as candidates when a user starts tap-flow-create from >> here. >> >> Actually, I want to add "tap-flow-create" and "tap-flow-delete" >> button on the pop up window that is shown when mouse cursor on >> an instance. >> Please refer p.3 of the attached file. >> >> But, currently very limited buttons are existing on the window. >> I think we need to discuss with Horizon and Nova team if we want >> to add buttons for tap-flow operations. >> I'm afraid that other operations (such as "create snapshot", >> "associate floating IP", and so on) have higher priority to be >> shown. >> >> >>> b. Color code the VM whose vNIC is attached to the destination >>> port of a tap-service. >> >> I agree. >> I made such an instance is colored light-blue. >> Please refer p.4 of the attached file. >> >> >>> c. BONUS: Allow the user to click on a VM that is serving as the >>> destination side of a tap-service and highlight all the VMs that are >>> attached to tap-flows associated with that tap-service. >> >> I think this is very nice to have, too. >> But it seems hard to implement. >> So, I'd like to try to this in the future. >> >> >> Regards, >> Soichi >> >> >>> Regards, >>> Anil >>> >>> >>> >>> __________________________________________________________________________ >>> >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: >>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >> >> >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev