Portal Design Considerations and Agile Development
As you can guess, it is a real design challenge to show all of Cisco’s developer assets in one website. We have a mix of audiences, ranging from some developers who are new to Cisco and just exploring to learn more about Cisco’s products and platforms to other developers who know Cisco’s products well and are in the middle of coding and want their downloads, APIs, and SDKs now. We also have a very broad portfolio of products that range from networking to data center to internet of things to collaboration, with a large number of products within each area. And, we have different owners for each of those product areas who we work closely with. And, we started with an older developer portal that had 126 tech centers with a combination of updated content and outdated content. Cisco’s portfolio is powerful, but these factors can make the seemingly simple task of “designing a developer portal” quite tricky.
We’ve taken an agile approach to our DevNet portal. The demand of having an improved developer portal was so strong that we chose to release early with the intent of iterating based on user feedback. We quietly released the DevNet portal in December and we received lots of feedback. Some feedback was very positive, with people saying it was the best place to find out about Cisco’s product portfolio and that it was really easy to find SDKs and downloads. Some feedback was “constructive”, with people saying it was frustrating to find what they want. We were even lucky enough to get some feedback in the form of a video blog post from Colin McNamara. We pouted about Colin’s public blog post for about 5 minutes, but then we got excited about actually getting active engagement from the developer community, which is a goal of ours. So, we sprung into action to really understand the feedback and do something about it. Many of the points were already in our roadmap for the DevNet portal, but we decided to accelerate some of the work the week of and weekend following his post to address many of the issues.
To provide a little background, as I mentioned it is a major design challenge to represent the developer resources associated with Cisco’s broad portfolio of products on a single portal. In order to address this, we created some innovative navigation tools for the DevNet portal. Specifically, we designed an innovative tile-based structure for navigation. We have a navigation filter bar that allows you to quickly filter down the tiles by domain, by product, and by content type to quickly get you to the tiles you want. You then click on the tile to get to your content. Some people didn’t realize that you can click on the filters (which is our problem, not theirs!), but once they understand the filters they feel that tile-based navigation is a very powerful construct. We’ll work on some of the visual design aspects to make the filters more apparent, but we’re keeping tile-based navigation since people do find it useful. That said, in response to the feedback, we reduced the number of content types in the tile navigation, hopefully making it more apparent where to find the APIs, SDKs, and tools. As an aside, we also have other site navigation options such as a DevNet API map, a drop-down menu, and search as other navigation options. I won’t cover those here, but the API map is worth taking a look at as well.
Our approach for the original DevNet portal launch was to 1) improve the most-visited content and 2) port over the rest of the content "as-is” with the intention of reformatting it and paring it down later on. Well, some of the developer feedback told us that the “as-is” content added a lot of extra tiles that made it difficult to find the content they want quickly and easily.
So, we drove forward with a huge site-wide content cleanup. You can imagine the challenge of porting over the developer content for Cisco’s full range of products when starting with a huge pile of content with both updated and outdated material, where all the material has different owners in different parts of the company. We poured through all the content on the site and removed lots of older outdated content, both consulting with the various product owners and making some executive decisions.
We also had a number of tiles that pointed to product pages. As mentioned earlier, some people found the DevNet portal to be a useful way to navigate through Cisco’s products. But, to a developer who is in the middle of coding (like @outlandmike), the tiles that point you out to product pages are pure noise. So, we decided to prune away all the pages that had non-developer-related content, especially the pure product content, thereby further focusing the Developer experience.
In summary, our stats for streamlining the content are as follows:
We started with 100 Dev Centers and reduced this by 18 to a total of 82 Dev Centers.
We started with 272 Tiles on the home page. We removed 43 tiles associated with the 18 removed Tech Centers and that took us to 229 tiles.
We reduced the number of content types and removed tiles that were no longer needed (e.g., Getting Started and Tutorials- but we embedded the content elsewhere), this removed 70 tiles taking us to 159 tiles.
We added 72 tiles for API’s, SDK’s, Code Samples, and Tools to match the filters taking us back up to 231 tiles.
The net is the following:
Dev Centers from 100 to 82 (-18)
Tiles from 272 down to 159 (-113) back up to 231 (+72), where the 72 new tiles have more relevant content.
Did this have an impact? I asked Colin, the original video blogger, and a number of other developers to try out the new-and-improved site without telling them too many details about the changes. Colin came back with the following feedback on Twitter:
The other developers were also able to find their SDKs much more quickly and gave positive feedback on the content improvement.
The video blog post also shared some thoughts around more deeply integrated software development experience. Our plan is to integrate with the tools that people use most, such as GitHub, rather than invent our own tools when a good one exists. We're talking with developers to understand the types of deeply integrated developer tools that people want from DevNet. We're in the defining stages, so please let us know your thoughts on this.
The Conclusion: Less is More
While the portal looks the same, it seems that the streamlining of content has greatly increased the usability of the DevNet portal. We’re happy about this feedback, but we’re not resting and we’re not finished. We still have many areas to improve and we’re adding more capabilities to DevNet. We're working on the evolution of our portal design. We’re more deeply integrating communities with the portal. We’re advancing our developer sandbox. We’ll be hosting a big developer conference. And, of course, we’re advancing our platforms and APIs. Also, we’re hiring to build out a great DevNet team. In a nutshell, we’re working like crazy to create a great developer experience and we have lots of goodies in store for DevNet developers over the coming months.
We’re excited to get engagement from the developer community. We want your feedback and suggestions, no matter how positive or how “constructive", and we will take it to heart. Our goal is to enable you to create awesome Networked Experiences for your customers and end users. We want to work with you to give you what you need to achieve this.
We hope this is the beginning of an interactive conversation. What do you think? Please keep the feedback coming and let us know how we can make DevNet valuable to you.
We have an issue where we are using SPOK to screen pop information on callers. This works most of the time but in some cases the TSP logs are not clearing out and not updating until after the call is answered. This results in the call info to pop from the...
A script would need to be created to pull/update information automatically within CER's database, how would I go about doing this? I know this is an abstract question, but its the best I can do at the moment to explain what it is I am trying to do. I...
Hello, Sorry if this has been posted in the wrong place but I in need of some assistance with getting Finesse call data out of UCCX.Currently we have the UCCX Platform and Finesse, where we can use Cisco Unified Contact Center Express Reporting which...
Hi, I want to store data which wont change over time. In that case, is it mandatory to hit Configuration or DB for every call?. Is there way to store configuration data to application level in UCCX script? Reading huge configuration during every call...
Trying to do the RESTCONF with YANG lab in the DEVNET labs
Trying to access the IOS XE on CSR Recommended Code Always-On Sandbox but I cant find the host/URL for the Sandbox to use in a Postman environment. Lab instructions are out of date.