ico-magnifying_glass
    ico-arrow-big-left

    Fujitsu - VPX Web Application Design Challenge

    PRIZES

    1st

    $1,700

    2nd

    $800

    3rd

    $250

    BONUS: 5‌ CHECKPOINTS AWARDED WORTH ‌$100‌ EACH

    Register
    Submit
    The challenge is finished.
    Show Deadlinesicon-arrow-up

    Challenge Summary

    Welcome to Fujitsu - VPX Web Application Design Challenge.

    On this opportunity, Fujitsu is building an innovative web application web application that runs on the VPX to support to lending and borrowing between the provider who wants to rent remaining power from the hardware having the high-performance GPUs and the user who want to use the remaining power from the provider on the mechanism using blockchain and P2P technology called VPX.

    We need your skills to design a visual concept for the web application that will manage the operations and user tasks.

    Best of luck.

    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.

    Full Description & Project Guide

    The goal of this challenge is to design a visual concept of the web application built on top of Fujitsu’s VPX technology. We’ll be providing information on VPX, user scenarios and rough mockups for you to use as reference.

    Application Background
    We recently ran an ideation competition where we gathered up the conceptual state of this application. We strongly encourage you to get acquainted with this domain before jumping in creating design proposals.

    The application you are going to design is a GPU sharing system created on top of VPX technology. The main user are AI researchers who don’t have enough available budget for research therefore cannot buy costly hardware with high-performance GPUs; however, they can use part of GPU hardware owned by other research institutions at a lower cost instead of using more expensive cloud services like Amazon AWS, Papersace or MS Azure.

    Typically, a AI researcher would want to create an AI model. When creating an AI model, a large amount of data needs to be processed, this means there is a need for large computing-processing power. Using high-performance GPUs are also known to dramatically reduce the time to create these AI models.

    For example, an AI model that can detect human faces from a single photograph will need thousands of different photographs with human faces on so that model can learn where the face is within a photograph. This model creation is called “training”, and once the model is properly created, the model should be able to detect a human face from any photograph almost instantly.  In a normal situation, researchers must run the training phase multiple time to create the best AI model possible.

    With normal computers, a single training phase could take weeks to complete. Where with an instance with high-performance GPUs, it can be reduced to days or even to hours. So having access to GPU instances with less cost is essential for a good research.

    Also, as you can imagine, for a research institution that can afford to buy these expensive GPU instances would get a benefit if they can “sell” unused time of these high-spec machines.

    To summarize the focus of this application in a high level, is to create a marketplace where a GPU owner wants to rent available data processing time (provider), as the researchers (consumers) can purchase and execute the available GPU processing time.


    Key concepts you need to know about VPX




    As described in above image, VPX is technology built on top of Blockchain. It creates P2P network with any organization involved in the network.
    Each organization will have an instance called “VPX Gateway” that makes up this network. These VPX Gateways hold blockchain’s distributed ledger. Within the network, organizations can exchange data safely without relying on centralized servers.


     


    The above image shows an overview of the network that this application you will design.

    This application will be built on top of VPX, where GPU provider’s and GPU consumer’s machines will be connected within the VPX network through each organization’s VPX Gateway.


    Concept Design Goals
    We are looking forward to using your design in a presentation, to showcasing the functionalities of VPX and what it could provide in this certain use case. It needs to be clear how this application is different and unique compared to existing infrastructures (AWS, Paperspace, etc) that do not use VPX. This means that functionalities listed below may not be incomplete neither be inconsistent. Aim to come up with a design that seems to work like the real application (hotspots in marvelapp - mandatory).

    Following are key design goals that client is looking for in your design:
    1. The design shows clearly the benefits and unique functionalities of VPX technology as explained above. Key principles are;
    1.a. A P2P distributed system that has no central server.
    1.b. User can securely and simply exchange data between each other. Every transaction is logged, and can exchange high confidential data securely without having to put those data somewhere else like a central 3rd party repository.
    -- Is there a way to make this evident? Maybe using an onboarding/welcome feature? Explore options!

    2. Attractive UI/UX
    2.1. Awesome and jaw-dropping UI design.
    2.a. Some keywords that the client is looking for in this design are;
    - Conceptual.
    - Future.
    - Powerful.
    - Three-dimensional appearance.
    - Cutting-edge technology.
    - Professional (meaning not childish or manga-like).

    2.b. The design must present the mechanism of GPU sharing business well and incorporates all the functionality mentioned in the requirements.

    2.c. You must include all the design components described in the Requirements and Scenario section below. You should also come up with your own components or functionalities that you think fits and necessary for this concept application. For example, reporting graphs showing the number of users, the total amount of money exchanged, distribution numbers of GPU instances per GPU type, etc, are all good information to show in one of the dashboards.

    User Roles
    This application supports features for viewing and managing the GPU items. You’ll design for all three roles:
    1. GPU Machine Consumer: typical researcher who rents GPU time.
    Persona: Dr. Ichiro who is AI researcher at University in Tokyo (we’ll mention as “ai@uni-t800” hereafter).

    2. GPU Machine Provider: research institutions who offer their available GPU time for renting.
    Persona: Research institute that possess hardware equipped with high-performance GPU (we’ll mention as “hw@gpurdg” hereafter). The following places represents the areas that will be hosting GPU instances:
    - uni-t800: A university in Tokyo.
    - oskai: An Osaka based Artificial Intelligence research institute.
    - res-sf: A research institute in San Francisco.
    - lml: A laboratory in London specialized in Machine Learning.
    - gpurdj: An IaaS funded by a consortium of universities in Rio de Janeiro.

    3. VPX Network Administrator: Fujitsu or VPX Service provider overseeing all the actions within this VPX network.

    Supporting Documentation
    1. Mockups: contains rough UI screens and flow explanation of the whole application.

    Screens Requirements
    Overall
    - IMPORTANT! This section describes the requirements overview. HOWEVER, you must deliver the proposed flow in the User Scenarios section. Use these Screen Requirements as scope guidance but what we need to see is the screens from the User Scenarios section, in the same order and flow.
    - Show hover/active states for buttons, dropdowns, breadcrumbs, errors/success states, elements with interaction, etc.
    - Please suggest how to organize this content and group them into screens, we are looking forward to see your unique proposals, be bold.
    - Propose a navigation system that makes sense and considers all the required features below.
    - All the screens provided in the mockups file must be designed.

    1. Login/Register
    User should be able to login using email and password. There should be a forgot password link. Social login/registration is not supported .

    Registration should require the following fields:
    - Email
    - Password
    - First Name
    - Last Name
    - Type of account: GPU machine provider | GPU machine consumer

    2. Dashboard
    See mockups file - pages 3, 4 and 5.

    Design a dashboard (main page), the one-way-data that allows users oversee the resources they are consuming/providing as well as listings. You must design three (3) dashboards consistently, some users can see/execute features that others can’t but the UI is essentially the same with those slight modifications.

    Note that every detailed information and action do not need to be designed within the dashboard, and you are free to come up with page transitions as you see necessary.

    Global View
    Within all the dashboards, the client is especially looking for a  cool component to express GPU distribution and usages. We call this the GLOBAL VIEW.

    This view should be the one-stop component where users are able to see GPU information, providers and consumers location information, communication speed, and the usage status, etc.

    This view is important as it should serve as a key design component when the client demo and present VPX technology to their customers. Please put your creative idea how to express this view to make this application fascinating.

    2.1. Dashboard for GPU Consumers
    Key information that needs to be shown are;
    • View of available GPUs with information like Manufacture, Product Name, GPU Chip, Released, Bus, Memory, GPU clock,  Memory clock, Shaders / TMUs / ROPs, Price, NewArrival, etc.
    • The state of the GPU currently being executed by the logged-in user (eg. elapsed time since the start of processing, etc.)
    • Used Cost/Fees summary and details

    2.2. Dashboard for GPU Providers
    Key information that needs to be shown are;
    • View of available GPUs
    • List of GPUs provided by logged-in user
    • Usage status of provided GPUs
    • Earned Cost/Fees summary and details

    2.3. Dashboard for VPX network administrator
    Key information that needs to be shown are;
    • View of registered GPUs
    • GPU usage status
    • Ranking and distribution number of various information of GPUs registered in the network. Eg.
      • Report of Spec, Frequency, Cost & Fees
      • Graph to show multi-dimensional information of the above reporting

    3. Search
    See mockups file - page 3/4/5.

    User should be able to quickly search and filter by certain criteria (explained in the user scenarios section). User should be able to see the search results as well.

    4. Register Training Dataset
    See mockups file - page 8.

    Machine consumer should be able to manage the datasets allowing the following features:
    - View a log of training history.
    - Add a new training data set (select from computer files).
    - Select available GPUs from the VPX network for training usage on a specific dataset.

    5. Data Training
    See mockups file - page 9.

    Machine consumer should be able to execute the action to train a selected dataset, as well as downloading the results after finishing. Consider showing a progress bar since this operation might take some time. Maybe including a queue concept? Open to ideas.

    6. Register GPU
    See mockups file - pages 11 and 12.

    Machine provider should be able to manage the GPUs allowing the following features:
    - View/edit/delete the computing resources.
    - Measure GPU performance on selected resources.
    - Manage requests for data processing from consumers (accept/reject).

    User Scenarios
    As mentioned above, please create the necessary amount of screens to display the described flows below.

    Separate each flow clearly in your physical files and marvelapp presentation. You can use blank screens with title labels such as “Consumer Scenario 1”, “Consumer Scenario 2”, etc, prior to entering to that specific scenario.

    (A) GPU Machine Consumer Scenario
    1. Consumer Scenario 1 - User ai@uni-t800 login to VPX network
    • ai@uni-t800 puts user id and password at user authentication page and logs in to the system.

    • The user will be taken to the dashboard page.

    2. Consumer Scenario 2 - ai@uni-t800 will see GPU information and their usage at the dashboard page.
    Dashboard will need to provide following;
    2.1 Show all available GPU instance details within a VPX network.
    2.1.1 Following are the summary items of each instance;
    Instance Summary
       Instance and Others
    • OS version [ex. Linux CentOS]
    • Main memory size [ex. 16GB]
    • Secondary storage capacity [ex. 1TB]
    • Communication Speed [ex. MB/Sec.]
    • Past usage information [ex. yes/no - can be some other info as well]
    • Fee [ex. $1.0/hr]
    GPU Spec
    Please refer
    • GPU Chip    
    • Memory    
    • GPU clock    
    • Memory clock    
    2.1.2 An instance should hold GPUs. Following are the information that should be shown when user wants a detailed GPU information;
    Detail
    GPU Spec
    Please refer https://www.techpowerup.com/gpu-specs/tesla-c2050.c923 for each of the sub items that should be written in the details.
    • Graphics Processor
    • Clock Speeds
    • Memory
    • Render Config
    Others
    • Result of performance measurement
      • Performance will be measured when the provider registers GPU device into VPX network. The unit of measurement is “Images Trained per Second”
    • Country/Region of where the GPU is at
    • Organization or the user who have registered this GPU device into VPX network
    Note: Please see this link for actual data of various GPUs https://www.techpowerup.com/gpu-specs/
     
    2.1.3 User should be able to narrow down GPUs with following conditions;
    • Performance
    • Fee
    • Communication speed
    • Past usage information
    • Secondary storage capacity
    • Frequency of use
    • Free word search
     
    2.2 Show newly added GPUs and deleted GPUs
    • The items displayed is assumed to show what’s written on above [2.1.1 instance summary]
     
    2.3 Show the usage of GPU
    • This will be the status of GPU that the logged in user is currently using. Like the time spent.
    • We want the UI to express so that GPUs are distributed on the network.
    • GPU (or a group of GPUs) should be represented by an icon, and the distance from the user should be described. For example, icons are placed on the globe, and distances of the network between a user are represented by the thickness of lines between icons.
     
    2.4 Dashboard should provide some way (link or a button) to show training data already registered.
     
    2.5 Dashboard should provide some way to register training data
    • The user needs to register training data in advance when using GPUs. The details will be described later at Consumer Scenario 3.
    • We assume that the user will click a button and move to [register training data sets] page in order to register training data set into VPX network

    3. Consumer Scenario 3 - ai@uni-t800 registers training data file within VPX and get approval to use the preferred GPU. Refer to supporting doc. Page 8
     
    3.1 Registers training data files
    • User registers path and size of the training files.
    • Note that within VPX network, the files will not be uploaded to some central machine.
    • After registering the files, the user goes back to the dashboard.
    • Dashboard should show files that have been registered near the register button.
     
    3.2 Narrow down the GPUs that can be candidates for training usage
    • The dashboard should only show GPUs that are capable of handling the file size registered (the item to show on GPU information are written above 2.1)
    • Additionally, user should be able to narrow down to find suitable GPU which meets his/her conditions such as higher performance, the cost/fee, and etc. (see 2.1 for the narrowing conditions)
     
    3.3 Send a request to the owner of the GPU hardware and obtain permission to use
    • Click the button to send usage request to the hardware owner and wait for the approval.

    4. Consumer Scenario 4 - Gather data after the training.
     
    4.1 When approved by the GPU provider, the system transmits training data with the processing command to the GPU and starts training.
     
    4.2 When training is done, user downloads the result data.


    (B) GPU Machine Provider Scenario
    1. Provider Scenario 1 - hw@gpurdg logs into the application and proceed to Provider’s dashboard.
    • The user should see a button to register GPUs, and a list of GPUs that has already been registered by this user.

    2. Provider Scenario 2 - hw@gpurd registers GPU into VPX network. Refer to supporting doc. Page 11
     
    2.1 User puts in GPU information.
    • Item to put should be the same as “User Scenario 1”.
     
    2.2 User pushes “Measure Performance” button to measure the performance of GPU which is “Images Trained per second”.
     
    2.3 Finally, a user will register the GPU by pushing the button to register.
    • Measured performance is reflected in [device detail] of the registered GPU. When registration is completed, resources are added to the GPU list registered with the user’s account.

    3. Provider Scenario 3 - Receive and approve the request to use the registered resource
    • Triggered by user scenario 3.3
    • Refer to wireframe Page 12
     
    3.1 When a user who wishes to use the registered GPU appears, a request comes via notification or emails.
     
    3.2 Provider confirms the details of the request and allows the usage.
     
    3.3 The system automatically starts to run the training with registered data that the user provided.
    • GPU will run the training and returns the result back to the user. The fee will be corrected after the execution.

    (C) VPX Network Administrator Scenario
    For the demonstration and promotion purpose of VPX, we will need a screen to show entire VPX view in addition to the above user and provider views.

    1. Administrator Scenario 1 - Administrator login to the system and see administrator dashboard
    • This administrator view should dynamically display the operation occurred within VPX in conjunction with the operation from GPU users and providers.
     
    The admin view should display the following;
    • VPX network topology
    • VPX Gateways connected in a network (There should be more than 10 Gateways shown)
    • The UI should show somehow that the Gateways hold distributed ledger of Blockchain.
    • GPUs connected to each VPX Gateways
    • Each VPX Gateway should have more than 1 GPU resources connected
    • Users (client machines) using VPX Gateways
    • Each VPX Gateway should have more than 1 user (or client machine) who want to use GPUs

    2. Administrator Scenario 2 - The admin view is expected to show the following scenes dynamically when implemented;
     
    [Scene 1] Provider resource registration
    • Refer to wireframe Page 5
    • Show new resources to connect to VPX Gateway
    • Display GPU information gets shared in all VPX Gateway’s distributed ledger
     
    [Scene 2] User request
    • Display the flow of a request from the user’s client machine to the GPU through VPX Gateway
     
    [Scene 3] Provider’s approval
    • Display the flow of acceptance to the user’s client machine
     
    [Scene 4] User’s GPU usage
    • Refer to wireframe Page 5
    • Display usage of GPU via the VPX Gateway from the user’s client machine


    Branding Guidelines
    - Branding is open to suggestions, colors and typography. Keep it serious, professional and modern.
    - Use a logo placeholder, but if you want to make it realistic, you can come up with something simple (a typography based logo would be fine).
    - Keep things consistent. This means all graphic styles should work together.

    Screen Specifications
    - Desktop: 1366px width. Height as much as needed.
    - Make sure your work is in a vector format, for retina scaling and high fidelity.

    MarvelApp Presentation
    - Request a MarvelApp prototype from me using this link: https://tc-marvel-app.herokuapp.com/challenge/30072924
    - Do not use the forums to request for MarvelApp.
    - Provide clickable spots (hotzones) to link your screens and showcase the flow of the solution.
    - Provide the MarvelApp shareable link in your notes during submission upload. See example.

    Stock Artwork (Illustrations, Icons, Photography)
    - Stock artwork is allowed for this challenge.
    - Make sure to declare all your assets properly or you might fail screening.
    - You don’t want to fail screening? Read this.

    Target User
    R&D professionals, AI researchers, High-spec machine power institutions (universities, AI laboratories, etc). Initially, targeted to users in Japan (copy must be in English).

    Judging Criteria
    - How well you have designed the items in “Concept Design Goals”
    - How much you were able to come up with new functionality or features that were not written in this spec but can be perceived as essential or nice to have when using this application.
    - How well you plan the user experience and capture your ideas visually.
    - How well you implement the challenge requirements. Note you would need to implement all required functionalities and items as written in the spec.
    - Cleanliness of your graphics and design.
    - Creativity and ease-of-use is key to the success as it must be engaging to users.

    Submission & Source Files
    Preview Image
    Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.
    Submission File
    Submit JPG/PNG for your submission files.

    Source Files
    All original source files of the submitted design. Files should be created in Adobe Photoshop, Illustrator or Sketch. Layers should be named and well organized.

    Final Fixes
    As part of the final fixes phase you may be asked to modify your graphics (sizes or colors) or modify overall colors. We may ask you to update your design or graphics based on checkpoint feedback.

    Round 1

    Submit your design for a checkpoint feedback.

    (A) GPU Machine Consumer Scenario
    1. Consumer Scenario 1
    2. Consumer Scenario 2
    3. Consumer Scenario 3

    (B) GPU Machine Provider Scenario
    1. Provider Scenario 1
    2. Provider Scenario 2

    (C) VPX Network Administrator Scenario
    1. Administrator Scenario 1


    - Please provide a MarvelApp Presentation (see details below).
    - Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03)
     

    Round 2

    Submit your final design plus checkpoint feedback.

    (A) GPU Machine Consumer Scenario
    1. Consumer Scenario 1
    2. Consumer Scenario 2
    3. Consumer Scenario 3
    4. Consumer Scenario 4 

    (B) GPU Machine Provider Scenario
    1. Provider Scenario 1
    2. Provider Scenario 2
    3. Provider Scenario 3

    (C) VPX Network Administrator Scenario
    1. Administrator Scenario 1
    2. Administrator Scenario 2

    - Please provide a MarvelApp Presentation (see details below).
    - Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).

    How To Submit

    • New to Studio? ‌Learn how to compete here.
    • Upload your submission in three parts (Learn more here). Your design should be finalized and should contain only a single design concept (do not include multiple designs in a single submission).
    • If your submission wins, your source files must be correct and “Final Fixes” (if applicable) must be completed before payment can be released.
    • You may submit as many times as you'd like during the submission phase, but only the number of files listed above in the Submission Limit that you rank the highest will be considered. You can change the order of your submissions at any time during the submission phase. If you make revisions to your design, please delete submissions you are replacing.

    Winner Selection

    Submissions are viewable to the client as they are entered into the challenge. Winners are selected by the client and are chosen solely at the client's discretion.

    Reliability Rating and Bonus

    For challenges that have a reliability bonus, the bonus depends on the reliability rating at the moment of registration for that project. A participant with no previous projects is considered to have no reliability rating, and therefore gets no bonus. Reliability bonus does not apply to Digital Run winnings. Since reliability rating is based on the past 15 projects, it can only have 15 discrete values.
    Read more.

    CHALLENGE LINKS:

    Screening Scorecard

    SUBMISSION FORMAT:

    Your Design Files:

    1. Look for instructions in this challenge regarding what files to provide.
    2. Place your submission files into a "Submission.zip" file.
    3. Place all of your source files into a "Source.zip" file.
    4. Declare your fonts, stock photos, and icons in a "Declaration.txt" file.
    5. Create a JPG preview file.
    6. Place the 4 files you just created into a single zip file. This will be what you upload.

    Trouble formatting your submission or want to learn more? ‌Read the FAQ.

    Fonts, Stock Photos, and Icons:

    All fonts, stock photos, and icons within your design must be declared when you submit. DO NOT include any 3rd party files in your submission or source files. Read about the policy here.

    Screening:

    All submissions are screened for eligibility before the challenge holder picks winners. Don't let your hard work go to waste. Learn more about how to pass screening here.

    Questions? ‌Ask in the Challenge Discussion Forums.

    SOURCE FILES:

    • Layered PSD files created in Adobe Photoshop or similar
    • Sketch
    • Adobe XD

    You must include all source files with your submission.

    SUBMISSION LIMIT:

    Unlimited