I keep seeing questions/requests around the NSO GUI. We have a very small GUI development team, and I would like to solicit input from this forum on how we can get maximum impact.
How do we think GUI impacts our sales? Our theory so far has been that our users don’t and wouldn’t use an NSO GUI for order entry. Can we validate that theory? Do we know of any NSO customers that don’t use some other system in front of NSO? How would such a customer be characterised? Certain size? Certain segment?
We could address our effort towards a number of audiences, e.g.
IMHO, I don’t think a self-service portal should interface with NSO – this scenario would require order management functionality, but I’d be interested in your views on this.
We have a small SP in Israel that purchased NSO last year and, at least for the time being, intends to use it directly.
The current GUI cannot really be used, as some basic functionality is not really working (at least the last time I checked).
For example, the topic that was discussed few times here before: If you have a yang model with leafrefs to device names and ports on these devices – the list of interfaces according to the selected device is not being populated, so the user cannot see a drop-down list in a manner similar to ncs_cli.
I think similar issues exist with leaves/containers conditioned by when-statements, but am not sure about it.
Anyway, I think that some small customers might want to use the GUI – it doesn’t have to be pretty, but I think they might want it to be able to provide the basic stuff that ncs_cli provides for service activation.
I also think that during pre-sale / poc we should be cautious not to raise false hope that the provided gui can provide service-activation capabilities similar to the ones that the cli provides.
Telstra Ops and Cisco IT has requested a useful NSO Web UI for templates
*Real* users, hurray, not “just” Cisco sales
Daniels team put something together to get them through a POC:
In my opinion, the best return for investment would be to improve the auto-generated GUI. This will immensely help pre-sales. With pre-sales, there is a certain audience type that only see the value-proposition if it is communicated to them via some decent GUI.
It can also help post-sales admin/operators for small and/or initial installations - at times customers (network engineers) are looking for an out-of-box portal. That is after they finish building the service-packages, they would like to try it out in production on a small part of their network. Building just the service-packages is a steep learning curve for them and then having to build a useable portal on top can be a big turn-off. Once they have successfully done initial deployment and want to expand, the organisation would be more willing to invest in a full blown portal solution.
I’m not convinced that “Example external GUI portal” would be of much value. There is a whole web-app industry out there, no point re-inventing the wheel.
Some of the line-items I’d like to be explored for improvement to the auto-generated GUI:
Agree with Bilal on auto-generated GUI being most impactful. Additional points to add:
If by “example external GUI portal” you mean a portal that is manually build to demonstrate one specific use case, this is certainly very useful to demonstrate that particular use case, but it might need to be modified to demonstrate other use cases.
Hope this helps.
I’ve been contemplating my response today. But no need as the ones below clearly capture our Advanced Services Mobility needs as well;
Working Gui to do POC, testing of new developed services, introduction of NSO to the customers without need for custom NB portal.
+1 for using GUI for POC’s and demo’s to customers who don’t have a NB portal.
It would be nice to have a stable GUI with enhanced look & feel and proper error handling with user-friendly messages.
I think it depends what you’re trying to sell. If you’re trying to sell NSO as a platform, then the generic operationally-focused GUI is fine. It’s a UI for NSO.
However, if you’re trying to sell (i.e. demonstrate or PoC) a very specific use case, then I think that a very lean and tailored UI is required. This will allow the customer to clearly see how NSO enables them to solve the specific operational issues or business outcomes they desire. Disclaimer: this is the approach that my team has taken in the construction of a PoC Web UI for NSO in APJ, so I am biased.
Our approach was presented at the previous SEVT (at the 1:21 mark): http://vtshare.cisco.com/p.jsp?i=2484
A video demonstration of our Layer 3 VPN use case portal for NSO: https://cisco.box.com/s/srcgrgbfi55rphxcijplnvihme1bp9dd
We are currently working as part of the global Agile Development Team in GSP to create a common portal framework for GSP pre-sales PoC’s and demonstrations.
.:|:.:|:. Richard Wade
Thanks for the link and great work on a portal framework.
One important question: Why are you using the REST API and not JSON-RPC or NETCONF? I worked with the EMEA innovation edge on a couple of project where we used NETCONF in Java (Tail-f open-sourced the client code) and it works great. With NETCONF you win transaction support and notifications. Notifications are a requirement when you use reactive fastmap.