At my last company, there was a dev/ops manager that was a ccna, ccnd, and some other certs. While many, if not most of feel that the "power" of configurations come mainly from using cli's and using programming for "glue", there is a strong appeal of having a strong GUI for many operations tasks. The dev/ops manager choose to explore Cisco competitors because they had a much stronger GUI and actually replaced some Cisco gear due to this. I think that the NSO GUI should at least be strong enough in functionality so that an executive making a purchasing decision can see some bling when comparing to competitors products. IE. You should be able to setup a quick PnP demo for example by adding a device (easily by an operator), adding in some IP addressing pools (easily by operator), and maybe creating a simple config template for IOS. It does not have to be doing a really complicated PnP configuration, but something that can demonstrate the power of NSO and also the potential ease of use once fully configured/programmed. I have taken the beginning NSO classroom course which I thought was really helpful in getting started and working with NSO demo's, IE. --local-install. I have just started working with the --server-install and live devices and found documentation on the transition a little on the weak side. As a newbie to NSO, I may be off quite a bit as I haven't found the most simply path to finding documentation.   First impressions are important in many things in life, so I think the GUI is the best way to make a good first impression. Some of the things I think the NSO GUI should do is: 1) Adding a device easily. It is not difficult to add a device through the cli or through the GUI.      - Currently there are some bugs in the "Add Devices" GUI process that result in an error. _spinner_WriteThPromise      - Under devices, choosing "+" vs pulldown menu "Add devices" results in two different screens. It looks like one is to add a real device and fails with above error, and the other is to create a dummy device.      - Adding a device in the cli requires multiple command line to add the device, and add to a device group.      - Adding multiple devices at once. I had to write a script to and more than one device, fetch key, sync, add a Compliance service. It was not terrible difficult once I understood a little more of the NSO engine under the hood... but I spent a great deal of time sifting through documentation in order to figure out how simple it was. 2) Deleting a device does not work in the GUI. You must remove it from the device group first or it give an obscure error message "illegal reference". After a while you see the ...device-group, and figure it out. The device does not show in the devices list or the device group list (if it hasn't scrolled off the page because the list is too long. See next item. You then have to revert, go to the device group, and remove from device-list and members, commit and then delete device. 3) Scrolling through the Device groups does not work. If the list of devices in a group is too long, it just disappears off the page 4) Adding a simple service in the GUI and cli. 5) Maybe working towards the PnP integration of other Cisco products as modules would be helpful. For example, I am planning to explore using Cisco's Estore product for order entry, IE ordering a new CVO for example. 6) NSO should make it rather painless to add devices, get some monitoring and add a compliance report. Being able to build some sort of compliance report along with the adding devices issue would be extremely helpfully in building a rather quick NSO instance that an end user could could add devices to and set up some compliance/monitoring would be pretty cool. What I envision from the GUI:      - Add a device or 2 that is fully compliant to your configuration standards      - Sync from the device      - Create a basic compliance service based on the device(s) configuration with some prompts on things that may be questionably different.      - Add 1000 of same devices      - Run a compliance report on all the devices and clearly show where devices are out of compliance      - Run a report on configuration changes on the devices vs the cdb 7) Reports/logging      - The GUI should have a Reporting section that has some basic reporting and logging features.      - Logging - ability to view all the different logs available configured in ncs.conf      - NSO configuration changes report      - User reports      - System/Performance reports      - Compliance (based on the above)      - Device Configuration changes 8) Errors clearly identifiable. If a GUI runs into an error, it needs to be clear about what the error is. You don;t want to be associated with Microsoft's famously ubiquitous errors over the past years. These make the product appear amateur and can bring question to the underlying product. If the GUI cannot perform a task properly, fix it or do not not add the function until it works or at least clearly defines the error. 9) The GUI has many quirks that should not be in any GUI today. Having to resize the screen, for example, in order to see what is suppose to be rendered does not look very professional in today's web based world. The ASA is a good example of a complicated OS where I use both the GUI (ease of quick monitoring check and some other config items) and the cli when I need the granular power it provides. NSO needs to cater to many audiences, Development, Operators, Management, etc. The GUI is what the non-dev teams will see more of and they can all end up being the deciding factor in the product purchase line. ... View more