Challenge Summary
Welcome to the Topcoder Developer Center UI Design Challenge.
This challenge is the second step of a large project in which we would like to leverage the community to create Topcoder’s Developer Center which will be the ultimate hub for developers to learn about Topcoder’s tools, APIs to allow them to create their own applications. Designed and built by the community to the community.
CHALLENGE OBJECTIVES
- To create the UI of 6 screens with subsections of the Topcoder Developer Center in desktop format keeping responsiveness in mind while designing.
- To provide a seamless flow to complete user goals.
- To explore the best way to organize and present a large amount of information.
- To apply the new Topcoder Design System, Brackets according to the rules stated below.
- Important! For this challenge we accept designs created in Figma only.
Round 1
Please provide the following screens for checkpoint along with your clickable Figma prototype with hotspots.- 1. Landing Page
- 3.1. List of APIs - List
- 3.2. List of APIs - Search Results
- 4. API Documentation - all sections included
Round 2
Please provide the following screens with checkpoint feedback incorporated for final review along with your clickable Figma prototype with hotspots.- 1. Landing Page
- 2. Getting Started Guide
- 3.1. List of APIs - List
- 3.2. List of APIs - Search Results
- 4. API Documentation - all sections included
- 5. Manage my Access
- 6. Support Channels
PROJECT OVERVIEW
- The Topcoder platform that we use every day has grown for over 21 years and has a vast array of APIs and toolkits that are incredibly powerful. However, these APIs and toolkits are not well documented, they are scattered across different GitHub repositories, and the existing API documentation is outdated. In addition, the existing developer portal doesn’t look like it belongs to Topcoder as it doesn’t follow the Topcoder branding. These make it difficult for a developer to leverage these APIs and toolkits for further development.
- This project aims to solve this pain point. With the new Developer Center, Topcoder can enable both internal and external client application developers to browse, consume, build, and test APIs for use in Topcoder client application projects. It also conveniently makes available several channels, such as FAQs, articles, forums, and blogs, that can be used to provide more information for the developers and to encourage developer engagement.
- We need your (our community members’) help to design and build it. This will be another tool that is entirely built by Topcoder community members. To engage more members to participate in this project will be fully run in challenges, e.g. all the requirements will be done in code, design, QA and F2F challenges.
- Recently we ran an ideation challenge in which we asked for members’ great ideas to design the functionalities, architecture, and technology stack of the developer center. As the next step we would like you to create the user interface for the developer center.
- In the meantime Topcoder’s UX team is working on Brackets, the new Topcoder Design System, that we would like you to use in this challenge. We would like the developer center to become a building block of the platform, hence the layout and style need to follow the existing rules/standards.
USER STORY
Krishna is teaching programming to young people and as he is a member of Topcoder for a long time he remembers how much he learned through challenges in the past, so he always encourages his students to register and try their new skills. To help this process, he would like to build a new tool into his course platform which lists new challenges for his students and also keeps a leaderboard among them.To be able to fetch the necessary data, Krishna opens the Topcoder Dev Center which clearly explains to him the process, and introduces the tools available. He starts to play around with API calls in the test environment, which helps him understand quickly what he needs for his own purposes. He can manage his access to the APIs and monitor the API usage over time.
AUDIENCE
- Developers around the world, who would like to use Topcoder data in their own projects.
- Designers around the world: In future versions of the Dev Center, we would like to scale this tool, so for instance the Topcoder Design System will be presented here (with design assets and code). This functionality, content are not in scope.
- Topcoder employees who work in product development, engineers etc.
GLOSSARY
- API: An application programming interface (API) is a connection between computers or between computer programs. It is a type of software interface, offering a service to other pieces of software.[1] A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that meets this standard is said to implement or expose an API. The term API may refer either to the specification or to the implementation. For instance, Topcoder’s Challenges API allows a developer to pull the registered members’ handles for a certain challenge and use this information in their own application.
- Access token: Access tokens are used in token-based authentication to allow an application to access an API. The application receives an access token after a user successfully authenticates and authorizes access, then passes the access token as a credential when it calls the target API. The passed token informs the API that the bearer of the token has been authorized to access the API and perform specific actions specified by the scope that was granted during authorization.
SCREENS/FEATURES
Please make sure your design includes the following screens/sections. We are open to your suggestions about information architecture and layouts as long as your proposal fits the new Design System standards.
- Global Screen Structure
As we are building another tool for the Topcoder ecosystem, the global structure should remain the same as the recently designed and developed tools, for which you can find some examples in the prototype shared in the challenge discussion forum. Read more in the Branding Guidelines section of the specification.
The Page Template
To help designers get started with working on a new screen, we provide a page template in the Design System as a component (with further nested components with variants). You can place an instance of this component to your canvas, detach it (only this component is allowed to be detached! Do not detach the nested components either!), and create the content according to the below descriptions. The pages should have the following structure:
- Navigation: The navigation is used globally on all tools on the platform, so we need to use the global navigation that is provided in the page template. The name of the tool goes to the navigation as an override, otherwise everything else has to remain the same.
- Breadcrumbs: From the second level onwards the platform uses breadcrumbs, which is also provided in the page template..
- Content: The page template provides 2, solely placeholder sections. This is the area where you are expected to place your design.
- Title: Most pages will have a main title, provided in the page template as a nested component.
- Content Sections: Your call! Please make sure that text container widths are kept within a pleasant, readable size. The optimal line length for body text is 50–75 characters, WCAG standards say width is no more than 80 characters or glyphs.
- Bottom CTAs: If the user has to take some main action on the page we use this component to provide these actions.
- Footer: Global element, needs to remain the same.
1. Landing Page
This page is the users’ entry point to the Dev Center, that should quickly summarize the aim and the possibilities in the tool and get them engaged. The information presented should be clear to help lead to all the content within the Dev Center.
We would like to include the following items on this screen (beside the global ones):
- Hero area: We provided some examples of other apps. Please explore these and create this section in a way that fits into the picture. This area should be used for a high level, relatively short introduction, and possibly showcase some features or certain tools offered.
- Search: Provide a search field/area where the user can start to search the database of the Dev Center.
- APIs showcase: Show the main APIs we offer.
- Articles: Links to relevant Thrive articles.
- Blogs: Links to success stories of apps built on top of Topcoder APIs.
- Support: A section that has a link to the Support Center.
- A link to Terms of Use (screen is not in scope).
2. Getting Started Guide
We would like to provide a step-by-step explanation of the steps the user has to take in order to get started, guiding them through the process like, acquiring an access token, using these credentials to initiate their first API call, etc. We provide some initial content that you can use in your designs. Show us how code snippets should look like in the tool. Also some elements that you should use on this screen:
- Breadcrumbs.
- Code snippets: You can take an example from here.
- Thrive / Blog articles section: Link to relevant Thrive articles, blog success stories.
- Content:
“Welcome to the Topcoder Developer Center! Here, you will find up-to-date documentation on all of the member-facing APIs we offer at Topcoder, as well as code samples and interactive demos to get you started! Why are we providing these APIs? What can you build with them? Check out these cool apps created by some of our members! [Links to projects] "OK, how do I build my own app like that?" - Here's a basic usage example of our Members API to display the highest ranked Algorithm members: ` Code ` Most of our APIs require an access token to access them, here is the procedure for acquiring a view-only access token to a particular Topcoder API: ` Code `”
3. List of APIs with Search Results / Filtering
This screen is an intuitively usable listing for all of the offered APIs, with a functional search feature. For the moment we offer 6 different APIs, but the tool should allow for more in the future. We would like you to create the two below states of this screen.
3.1 List
On this screen initially the user will be provided with a list/grid of APIs, along with a search field and filtering functions. These are the publicly available Topcoder APIs:
- Challenges API
- Resources API
- Projects API
- Groups API
- Members API
- Gig Work API
3.2 Search results
Upon entering a keyword (e.g. member) and initiating the search, the user will be provided with a list of available requests from all the APIs. Clicking on one of these, the user would be taken to the next screen (API Documentation), and shown the details of the request concerned. The user would land on this screen as well, if they initiated a search on the landing page.
4. API Documentation
This is the main content provided by the Developer Center. The helpful, useful, and usable API documentation page you'd wish to see. For each API we will provide the same format. For each API there is a considerable amount of different information that needs to be organized in an easy to understand, easy to navigate manner. The below list contains these sections. We would like you to explore the possible structures and come up with the best solution. E.g. you might try to use tabs (provided in the Design System), some secondary navigation, you could try to combine some of the sections, where it makes sense.
4.1 Overview
A general description of what the API can be used for, what data users can fetch by using it with what restrictions.
4.2 Documentation
This section is the main part of the documentation, where users can find out about the available request and the sample of outputs they will get to those requests. It is also a common practice to show code samples in different programming languages (like here) that users can copy and try. Please check some of our existing documentations to get an idea about this content.
4.3 Test Environment
A "try-it-out" page, where users can test requests. Explore the different opportunities, layouts for this purpose. Some examples:
- Topcoder API documentation (member search)
- Topcoder Member API Swagger documentation
- Marvel API playground
4.4 Change Log
APIs are not static. From time to time API developers may add new functionality and update to a new version. In this case client app developers can also decide to update by using another version. In the log, the user can find information bout the available versions of the particular API. Example for a change log.
4.5 Discussion Forum
In this section users can communicate with the Topcoder team and with each other about the API. The discussion forums will utilize the existing Topcoder Forums, and will be embedded into this page/page section. Check the general forums for a reference. You can use screenshots of the existing forums.
5. Manage My Access
Users need to request access tokens for authentication purposes to be able to use the APIs. They might have one or more tokens, and should be able to manage them and monitor the usage. We would like to provide the following functions to our users:
- An ability to request access tokens
- An ability to revoke access tokens
- An ability to check their API usage: a simple reporting function with visualization (graphs) providing some metrics. Initially we will show number of API calls. For your reference, a complex monitoring system: Google Maps JavaScript API Monitoring.
6. Support Channels
This screen provides central point for help with links where the user can find additional information in the following forms:
- Frequently Asked Questions
- Link to general Discussion Forums
- Link to Topcoder Support
DEVICE SPECIFICATION
- Desktop - 1440 px width
- Mobile - not in scope
DESIGN GOALS & PRINCIPLES
- Easy to use interface, that guides the user through the process
- The main target group is developers, but we should be able to welcome and engage beginners, and people from other fields as well, so the entire tool should provide crystal clear information.
- The design should be created with responsiveness in mind, the layouts should be easily translated to a mobile experience (not in scope for this challenge).
- The style and the layout should adhere to Brackets, the new Topcoder Design System.
- Coming up with a layout for the content part that can handle a relatively complex content.
BRANDING GUIDELINES
In this challenge we will ask you to use the brand new Topcoder Design System, Brackets, presented to you in a Figma file with documentation of the numerous components provided in the file. On Wednesday, 18 May at 10am ET, we will host a workshop for designers to show you around in the Design System and answer questions (Register here). The below guidelines are important, please read and follow them carefully.
Here is how you are expected to manage your files and submissions:
- Download the Figma file from the Discussion Forum and save it in your project folder.
- You will have to work in this file and submit the same by the deadlines.
- You will have to submit the exported fig file as a source, not only the link.
- You will have to submit the link to your Figma Prototype (check this out for help).
Below are the rules that you need to follow during your design process:
- Utilize, reuse the existing components as much as you can, so we don’t create duplicates for the same functionality.
- DO NOT DETACH COMPONENTS from the library! Detaching components may result in disqualification. Your source file will be checked during checkpoint review for these rules.
- Explore the components and the documentation in the file to get a full understanding of the availability and possible restrictions.
- Explore the typography and color styles and do not deviate from them.
- Use an 8px grid.
- Work on the ‘UI Design’ page of the Figma file only
- Do not modify anything on the ‘Brackets Design System’ page
- Place your local components if you create any to the ‘UI Design’ page, to a separate location from your screen flows.
- Please create your screen flows horizontally, each screen and its interactions/states occupying a row.
JUDGMENT CRITERIA
- Creativity: Conservative; barely new ideas, use what is already proven to work.
- Exploration: Flexible in terms of the content section; follow the provided screen requirements section and propose improvements or different paths that positively impact the user goals. BUT strict concerning the usage of the design system.
- Aesthetics: Hi-fidelity design; provide a top-notch finished looking visual design.
- Branding: Strict; carefully follow the provided Design System and stick to them.
DESIGN ASSETS
The below item has been shared in the challenge discussion forum.
- The Brackets Figma library
- Prototype showcasing the existing apps designed for the platform for reference.
STOCK PHOTOS AND ICONS
- Photos: use only free photos from the sites allowed by Topcoder.
- Icons: use icons only from the design system or create them by yourself to be in line with the other icons.
- Fonts: use fonts only from the design system.
FIGMA PROTOTYPE
We use Figma’s prototyping functionality to showcase your design to our client.
- Create a clickable prototype linking up all your screens.
- Share your Figma prototype link in your Declarations.txt when submitting.
FINAL DELIVERABLES
You have to submit a single zip file that includes the following 4 items:
- Source.zip
- Original source file (fig) exported from Figma. The link is not sufficient.
- Create files in Figma.
- Submission.zip
- Your screens exported as PNGs
- Declarations.txt
- A text file that contains all the notes about font usage, photo and icon declarations and your Figma Prototype link
- Preview.jpg
- Create a JPG preview file of 1024 x 1024 px
Please read the challenge specification carefully and watch the forums for any questions or feedback concerning this challenge. It is important that you monitor any updates provided by the client or Studio Admins in the forums. Please post any questions you might have for the client in the forums.