Spearhead
/
joyent-portal
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

cleanup

Sérgio Ramos 2017-10-11 10:59:46 +01:00
parent dddd39c055
commit 74c0b86ae2
25 changed files with 0 additions and 1003 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

143
01.02.2017:-Project-Catch-Up.md

@ -1,143 +0,0 @@
**Present from Joyent:** @misterbisson
**Present from Make Us Proud / YLD:** @AnthonyMann, @antonasdeduchovas, @luisklefsjo, @alex-windett, @juditgreskovits, @ajones5876, @hanalodhi
## 1.) New team member Hana!
@hanalodhi She will be on this project for a week as an introduction to the company and what we do.
## 2.) Collection of Product Narratives so far
What you see today are not all the wireframes available... All prototypes will be collected here in the [Wiki] (https://github.com/yldio/joyent-portal/wiki/Prototypes)
* Sign Up https://marvelapp.com/1d5902h/screen/24487210
- We added a counter to see how many step you need to
- Password and security are now on the same page, based on testing results
- Add billing details
- Be part of an organisation
* Creating new organisation https://marvelapp.com/1h8e5i5
* Managing organisations' tabs https://marvelapp.com/4jgd2he
* Creating a new project https://marvelapp.com/1h8gbd3
* Empty project https://marvelapp.com/4jgiafh
* Viewing services https://marvelapp.com/29i96g1
This is a new flow
- Name your card
- Question: Why auto-pinned to the tabs bar? This will be worked on further
Activity feed https://marvelapp.com/3ddi4g1
* Scaling https://marvelapp.com/1d5f3dg
* Add a project
- Name it
- Use existing card or add a new one
* Allow people to configure services through the manifest file [#167] (https://github.com/yldio/joyent-portal/issues/167): https://marvelapp.com/2jegi07/screen/24429445
* Allow people to add services [#169] (https://github.com/yldio/joyent-portal/issues/169): https://marvelapp.com/ej9b136/screen/24489183
The priority has been changed to repositories first rather then edit the manifest
- Thought: Add “input from library”?
- Do we want to focus on “Project” or a “Service” from the repository (Casey to think about this and get back to us). We might want to highlight that we are importing a “whole project”
Working with instances (Unmanaged Instances??)
- To make sure we don’t clutter the opening page, the user needs to go the respective tab - “Services” or “Instances”
Manage Organisations
- Orgs can be pinned or unpinned (this will be worked further)
This is sort of in process… there are still a few things to iron out that have yet not been considered
Viewing the project from different perspective
- Visually differentiate the consul from the rest of the topology
Scaling services (Slight update)
- Lightbox has been stripped a bit based on feedback from testing
Service Rollback
- The Rollback is now an independent item on the tab menu
- The order of the versions have been swapped (current -> new version)
- Educational components have been added - wording not final
Activity Feed
- Project Feed
- Service Feed
- Instance Feed
Events, Alerts
Events or activities are collapsible to avoid clutter. If you click on them, they reveal more information. If that is not enough, the user can be taken to that specific area.
Configure services through the manifest file
- A text editor
- Support and learn component
- As the user types, the editor recommends “copy”
- Elements that can be auto-populated will be
- Tooltips
- Error message/indicator to highlight if there is a string of code that doesn’t appear
**Note from Casey:**
The name that you give the service, doesn’t have to conform to anything. It doesn’t have to be anything that is recognised
It is better to call it after what role it plays rather than what software it is.
Let’s try to back away from creating name conventions, but rather come with helpful suggestions.
Add a service from Topology view
- Lightbox that follows that previous UI-patterns
- Maybe move the Project name into a separate section to remove the complex element for the user??
- The Image could be an important thing for the user…
- a pre-defined template with a prompt of 'image' name suggestion instead. Once template is filled, then possibly decide a name later?
## 3.) Technical Update
* @juditgreskovits: creation of a new project
- [here] (http://frontend.svc.f4b20699-b323-4452-9091-977895896da6.eu-ams-1.triton.zone:8000/biz-tech/projects)
* @alex-windett: adding people to a project and editing roles
- [here] (http://frontend.svc.f4b20699-b323-4452-9091-977895896da6.eu-ams-1.triton.zone:8000/biz-tech/projects/forest-foundation-dev/people)
* We are also starting to put together technical documentation
- https://github.com/yldio/joyent-portal/tree/master/docs#prototype-joyent-portal-docs
## 4.) Questions?
* Service lifecycle
** Note from Casey:**
Concerned about anything that is depending on consul - We don’t know the connection between the consul and dependencies as consul never shows the information
- topology connections determined by container pilot upstreams (current design doc of container pilot v3 does not show this upstream and needs to be updated)
- integration with consul is difficult therefore no dependency on consul desired, assumption is that the manifest defines connections and user (possibly) receives error message if a service doesn't connect
“You told us to connect, but at the moment it is not available. We will try again”.
## 5.) What’s next?
Next week Casey is in Korea, so any meetings would have to be AM GMT (afternoon Korean time).
Wednesday should work, but Casey will confirm early in the week - MUP to send out invite for 08:30AM (GMT)
## Minutes:
### Services
- Import from library of sample manifests ???
- Do we emphasise project or service manifest?
- When importing from GitHub do we discrete service or a whole application/project - it may be easier to do application/project
### Instances
- Terminology --> "unmanaged" instead of "legacy" instance
### Technical Components
- Build Project / Org creation
- "No services" module
### Scaling
- When the price increases with a new data center, is green the best colour to use?
### Activity flow
- Is a search input the best thing? What would they filter by? Maybe checkboxes that filter down by action type? *just a mental note*
### Manifest Editor
- Just a note, there should possible be no autocomplete on the __nginx__ name. Its similar to a string so shouldn't be guessed by system
- Should be better to use what the service will be delegated
- Maybe eliminate service name so that they can get started straight away with the complex stuff.

61
07.02.16:-Project-Roadmap.md

@ -1,61 +0,0 @@
**Present:** @antonasdeduchovas, @alex-windett, @juditgreskovits, @ajones5876, @ramitos, @AnthonyMann, @raoulmillais
**Time:** 11am-1pm
## 1.) What have we done so far? Where are we at?
* What are our priorities?
**Antonas to share the doc with the list of priorities**
Doc: https://drive.google.com/open?id=1OwdoSk3CT0IXQWDrcLtrf_ZtffhQ6OaCYIHETE3wkQU
* We should prioritise narratives that rely on data as these will be most difficult to accomplish
## 2.) What do we want to achieve in 6months?
* What does the Minimal Loveable Product (MLP) look like?
* What does success look like?
* We should identify a baseline (after talking to Casey) and then try and create something that goes way beyond that
* We need to make sure that the project scales
* What should the technical prototype actually prove?
* Prove Joyent's value to enterprises
## 3.) General Communication, Key milestones, Project Roadmap
* What is our process?
* GitHub Project boards
* Tightening communication between engineering and design
## 4.) What are we working on at the moment?
## 5.) GitHub project boards
* Assignment of short term issues
## 6.) Current build
* Create tickets for existing bugs / discrepancies against design
* Isolate bugs / issues related to styled-components
* Discuss approach to structuring data in Redux store especially in relation to existing data (whether it needs to be changed) and data to be added given priorities established
* Containers vs components - connected components are containers and so should live in containers directory, all other components, including forms live in components directory
* Overhaul of UI components - ensure all components use custom styled-components / normalizer styled base components and that they confirm to design guidelines for these components and that spacings conform to baseline rules
* Overhaul of frontend codebase to ensure above is applied there too
* Restructure / evaluate existing front-end tickets
## 7.) Prep for meeting with Casey
## Other:
* GitHub project boards (and general open sourcing)
* Can use summary of Casey's last visit to London as a reference: https://docs.google.com/document/d/1iKXiq0p1kyNvaQtkzQy_kymxMtRB0Iivyru4eUhCLfw/edit
* Need to get details of a sample application (there must be some big ones created by YLD)
## Notes:
* Need to do more research on linking with GitHub (GitHub will provide a great deal of leg work here). Would be awesome though, if when your GitHub account was connected, you'd then have a list of repos and then having a one click deploy
* Question for Casey: do we just focus on Docker style containers for instances?
* The idea of having metrics for certain categories was positively received
* The concept of adding 3rd party metrics, Prometheus is highlighted as the Joyent preferred service at the moment
* Will there ever be a need to role back a project?
* How can we bring in the wider Joyent ecosystem?
* Some issues highlighted around testing when linking between a technical prototype and a marvel prototype
* Need to get data structure sorted out now, as this will heavily link in with the RBAC (however, it was highlighted that this might be rebuilt at a later stage anyway)
* We need to go through these priorities every couple of week
* Once we have spoken to Casey, all of these priorities need to be communicated on the GitHub board into narratives, and more granular pieces for the technical team
* These GitHub boards will then be referred to every morning in standups
* AJ to do: increase confidence of narratives and documents everything
* Antonas to do: designing elements for Taxonomy and Navigation, Mobile designs, record videos for wireframes
* Judith to do: creating the technical prototype for topology
* Alex: making the technical prototype mobile responsive

215
08.02.17:-Project-Catch-Up-with-@misterbisson.md

@ -1,215 +0,0 @@
Original Google Doc: https://docs.google.com/document/d/1bLgAg2i9FSpexpDtM3SZ1LJKq2adsWOyQK8C_XVVnFw/edit?usp=sharing
# **Project Catch Up**
**Skype, 08.02.17**
## **Meeting aim**
* To discuss priorities for the next six months
**Joyent: **
* **Casey Bisson **
**MUP/YLD: **
**Anthony, Antonas, AJ, Alex, Judith, Sergio**
## **Agenda **
1. **Our list of priorities over the next six months:**
* Document outlining everything we have worked on so far: [https://drive.google.com/open?id=1OwdoSk3CT0IXQWDrcLtrf_ZtffhQ6OaCYIHETE3wkQU](https://drive.google.com/open?id=1OwdoSk3CT0IXQWDrcLtrf_ZtffhQ6OaCYIHETE3wkQU)
* The below table was created by thinking about what is the MVP (Alpha), what is the MLP (Beta) and then what are supplementary features we could create if we had time (Growth).
<table>
<tr>
<td></td>
<td>Alpha (High Priority)</td>
<td>Beta (Medium Priority)</td>
<td>Growth</td>
</tr>
<tr>
<td>Highest Priority</td>
<td>Sign up</td>
<td>Deploying instances</td>
<td>Container pilot catalogue</td>
</tr>
<tr>
<td></td>
<td>Deploying with Git</td>
<td>Activity Feed</td>
<td>Volumes/manta</td>
</tr>
<tr>
<td></td>
<td>Stopping/starting/ reprovisioning</td>
<td>Deployment Queue</td>
<td>Duplicating/ copying a project</td>
</tr>
<tr>
<td></td>
<td>Scaling</td>
<td>Automatic Deployment</td>
<td>Transferring</td>
</tr>
<tr>
<td></td>
<td>RBAC</td>
<td>Adding instances/services</td>
<td>Deploying by uploading manifest</td>
</tr>
<tr>
<td></td>
<td>Taxonomy/
Navigation</td>
<td>Rollback/updates/
version control</td>
<td>Deploying by writing manifest</td>
</tr>
<tr>
<td></td>
<td>Visualising Metrics</td>
<td>Adding/editing metrics</td>
<td>Security auditing</td>
</tr>
<tr>
<td></td>
<td>Billing Management</td>
<td>Setting up alerts</td>
<td>Environments</td>
</tr>
<tr>
<td></td>
<td>GitHub version syncing/
visualisation</td>
<td>Logs</td>
<td></td>
</tr>
<tr>
<td></td>
<td>Deleting</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Lowest Priority</td>
<td>MOBILE</td>
<td></td>
<td></td>
</tr>
</table>
* Growth: how can we bring in the wider Joyent ecosystem?
2. **Our priorities for the technical prototype:**
* The below table was created by thinking about the features that can only be tested in a technical prototype, for example ‘visualising metrics’ as this feature needs live data for a user to understand how this feature works correctly.
<table>
<tr>
<td></td>
<td>High Priority</td>
<td>Medium Priority</td>
<td>Low Priority</td>
</tr>
<tr>
<td>Highest Priority</td>
<td>Taxonomy/ Navigation</td>
<td>Adding & Editing metrics</td>
<td>Stop/start/
reprovisioning</td>
</tr>
<tr>
<td></td>
<td>Visualising Metrics</td>
<td>Setting up alerts</td>
<td></td>
</tr>
<tr>
<td></td>
<td>GitHub Deploy</td>
<td>Logs</td>
<td></td>
</tr>
<tr>
<td></td>
<td>Scaling</td>
<td></td>
<td></td>
</tr>
<tr>
<td>Lowest Priority</td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
3. **New wireframes**
* *Managing organisations - **[https://marvelapp.com/4jgd2h*e](https://marvelapp.com/4jgd2he)
* *Scaling, deployment queue and activity feed narrative - https://marvelapp.com/1d5f3dg*
4. **Technical Update**
* *Judith to place link here*
5. **Questions?**
* If not asked already, are we happy with a heavily reliance on GitHub?
* Do we just focus on implementing Docker style instances?
1. Infrastructure and hardware/VMS
2. Are we using the correct terminology here?
* Third party metrics solutions. Is Prometheus the preferred one?
* When rolling back a service, does this then create a new version of the project?
6. **What’s next? **
## **Meeting notes:**
* Casey will go through priorities and suggest some improvements
* Casey suggested that GitHub versioning shouldn’t necessarily be a priority, the source of truth stays inside Joyent: the product
* The users could use a CI tool, such as [https://jenkins.io/](https://jenkins.io/), to maintin synchronisity with GitHub/GitLab etc : this does need some clarification
* In the short term the asynchronousy between joyent manifest and github manifest is in back lock for the time being.
* [https://github.com/joyent/rfd/blob/master/rfd/0036/stories/jupiter-example-com-jenkins.md](https://github.com/joyent/rfd/blob/master/rfd/0036/stories/jupiter-example-com-jenkins.md)
* Joyent CLI tools to encompass GitHub integration instead.
* Versioning:
* This is v. important and has to be done very well.
* When creating an update, we use this update more as a pointer, than a role back
* Casey will provide some clarification here
* Links Casey shared to try and explain this: [https://github.com/misterbisson/rfd/blob/rfd36-kiener-feedback/rfd/0036/README.md#project](https://github.com/misterbisson/rfd/blob/rfd36-kiener-feedback/rfd/0036/README.md#project)
* [https://github.com/misterbisson/rfd/blob/rfd36-kiener-feedback/rfd/0036/projects/triton-projects-cli.md#triton-project-reprovisionrestart---serviceservice-name-or-uuid---versionversion-uuid---imageimagespectag---instancenameuuid---compute_nodeuuid---countcanarypositive-integer-rollingpositive-integer](https://github.com/misterbisson/rfd/blob/rfd36-kiener-feedback/rfd/0036/projects/triton-projects-cli.md#triton-project-reprovisionrestart---serviceservice-name-or-uuid---versionversion-uuid---imageimagespectag---instancenameuuid---compute_nodeuuid---countcanarypositive-integer-rollingpositive-integer)
* When you rollback you change the default / active manifest to a previous version but the latest version is not used or deleted.
* There maybe be something that you get current logs and metrics but previous or past history is something that is yet to come.
* Maybe bump these up to alpha
* Casey brought Richard onto the call who gave us a tour of Prometheus: [https://prometheus.io/](https://prometheus.io/)
* Recorded video of this tour is in Slack: [https://joyent-portal.slack.com/files/alexjones/F437DLVEK/zoom_0.mp4](https://joyent-portal.slack.com/files/alexjones/F437DLVEK/zoom_0.mp4)
* Need to support traditional and unmanaged instances. This include VMs

3
1.-User-Interface-(UI)-Design.md

@ -1,3 +0,0 @@
This part of the documentation is split into two parts: <br>
1. Joyent's stylistic tooling.<br>
2. Joyent's visual rules/library

26
10.11.16:-Explore-how-different-environments-fit-into-the-application-structure-(Dev,-Staging,-Prod-etc).md

@ -1,26 +0,0 @@
**Documented from: https://github.com/yldio/joyent-portal/issues/75**
**@antonasdeduchovas:**
We had an initial workshop, here's a brief report:
https://drive.google.com/open?id=0B1oWObk56wa5U3pTZEtZc2E4blU
We need to gather a bit more feedback from the users, but certain UI components are already being introduced to the wireframes
Here's a proposition for a content structure, that includes deployment environments:
https://drive.google.com/file/d/0B1oWObk56wa5OGZZdlRqaXRwNkU/view?usp=sharing
It might require some changes, based on Elijah's interview
**@misterbisson:**
Regarding https://drive.google.com/file/d/0B1oWObk56wa5OGZZdlRqaXRwNkU/view
How many developers are working on the Joyent Platform project?
Can all those developers share a single development environment?
Do people need a single staging environment, or do that need many?
Is there a single, sequential pipeline from development to staging to production? Or, do some features sometimes make their way to staging, are discovered unsuitable for production, and then kicked back to development?
My answer to those questions:
People usually need a development/staging environment for every feature and bug fix they decide to pursue. A single developer may be working more than one feature, and then be interrupted by a bug fix, and then be interrupted again by a higher priority bug fix. Each of those needs its own development environment.
Ideally, the development environment can offer most of the features we'd expect of a staging environment in terms of previewing the working product, but operators will need to test different approaches to deployment and need to have multiple staging environments (possibly with different starting conditions) to which they apply the upgrade code using different workflows to test their deployments.

1
11.11.16:-Local-Development-with-Portal.md

@ -1 +0,0 @@
See this Google Doc: https://docs.google.com/document/d/1XC-zHajKuccXx_i8_aXofZghRybomXzFxOu9nIVu628/edit#

1
13.10.16:-What-might-go-on-the-dashboards?.md

@ -1 +0,0 @@
See this google doc: https://docs.google.com/document/d/1whUTDkkBGCKtZAXMbR7paULafKzwzE3HyvOjUr3JIHw/edit

3
15.12.16:-Internal-Catch-Up-(prioritising-what's-next).md

@ -1,3 +0,0 @@
Documented from this GitHub issue: https://github.com/yldio/joyent-portal/issues/104
See this Google Doc: https://docs.google.com/document/d/1RFHoFSfkpKI1TvZokTaebnVKzrk9LPVRNUWib_8eLVc/edit

1
17.11.2016-Casey-in-London.md

@ -1 +0,0 @@
See this Google Doc: https://docs.google.com/document/d/1iKXiq0p1kyNvaQtkzQy_kymxMtRB0Iivyru4eUhCLfw/edit?usp=sharing

6
2.-User-Experience-(UX)-Design.md

@ -1,6 +0,0 @@
This part of the documentation is split into two parts: <br>
1. Joyent's animation, tooling and UX flows. <br>
2. Joyent's behavioural flows. <br>
Persona's are here.

1
21.10.16:-Adding-teams-to-Role-Back-Action-Control-(RBAC).md

@ -1 +0,0 @@
See this G Doc: https://docs.google.com/document/d/18gUlu4TiufQPJkKUFktHWucwqO0rvXUFhIepRBP4Qnk/edit#

1
22.11.16:-Learn-about-available-container-monitoring-capabilities-(thresholds,-trends,-alerts-etc).md

@ -1 +0,0 @@
See this google doc: https://docs.google.com/document/d/1M_lDFzTZSZ-dnP2Z3a8EnoC77qwGZI9zI-ScmEoEibs/edit

1
27.10.16:-Abstracts-and-Quick-Actions.md

@ -1 +0,0 @@
See this G Doc: https://docs.google.com/document/d/1PPhnygOzxNc6RD-JmfetNFWswnmLn9rjA0fM0eL3-XU/edit

1
3.-Coding-Implementation.md

@ -1 +0,0 @@
This part of the documentation is split into two parts: 1. Joyent's code style and tooling. 2. Joyent's implementation of the code

19
Home.md

@ -1,19 +0,0 @@
![Joyent Logo](https://p6.zdassets.com/hc/settings_assets/150338/200244868/aLLNFxDSjixwI4gvAdIGUg-joyent_logo2.png)
Welcome to the joyent-portal wiki!
This wiki is created to guide open source contributors through the best ways to get involved with the Joyent project.
If you want to get stuck in, please see our active projects [here](https://github.com/ajones5876/designflow/projects/1). However, to make sure your work is featured, it's recommended to read through the below documentation first:
* For User Interface (UI) designers go [here](https://github.com/yldio/joyent-portal/wiki/1.-User-Interface-(UI)-Design)
* For User Experience (UX) designers go [here](https://github.com/yldio/joyent-portal/wiki/2.-User-Experience-(UX)-Design)
* For coders go [here](https://github.com/yldio/joyent-portal/wiki/3.-Coding-Implementation)
For general research: [here](https://github.com/yldio/joyent-portal/wiki/Research)
For meetings go [here](https://github.com/yldio/joyent-portal/wiki/Meetings)
For user testing go [here](https://github.com/yldio/joyent-portal/wiki/User-Testing)
For a list of prototypes go [here](https://github.com/yldio/joyent-portal/wiki/Prototypes)

32
Meetings.md

@ -1,32 +0,0 @@
# We document our meetings with Google Docs, to access our public folder go [here.](https://drive.google.com/open?id=0B1oWObk56wa5N1VzZjhZWWpDTTQ)
***
## [08.02.17: Project Catch Up with @misterbisson] (https://github.com/yldio/joyent-portal/wiki/08.02.17:-Project-Catch-Up-with-@misterbisson)
## [07.02.2017: Project Roadmap] (https://github.com/yldio/joyent-portal/wiki/07.02.16:-Project-Roadmap)
## [01.02.2017: Project Catch Up] (https://github.com/yldio/joyent-portal/wiki/01.02.2017:-Project-Catch-Up)
## [22.11.2017: Learning about available container monitoring capabilities, thresholds, trends, alerts etc] (https://github.com/yldio/joyent-portal/wiki/22.11.16:-Learn-about-available-container-monitoring-capabilities-(thresholds,-trends,-alerts-etc))
## [17.11.2016: Casey in London] (https://github.com/yldio/joyent-portal/wiki/17.11.2016-Casey-in-London)
## [15.12.2016: Internal Catchup, prioritising for next stages] (https://github.com/yldio/joyent-portal/wiki/15.12.16:-Internal-Catch-Up-(prioritising-what's-next))
## [11.11.2016: Local Development with Portal] (https://github.com/yldio/joyent-portal/wiki/11.11.16:-Local-Development-with-Portal)
## [10.11.2016: Explore how different environments fit into the application structure Dev, Staging, Prod etc](https://github.com/yldio/joyent-portal/wiki/10.11.16:-Explore-how-different-environments-fit-into-the-application-structure-(Dev,-Staging,-Prod-etc))
## [27.10.2016: Abstracts and Quick Actions] (https://github.com/yldio/joyent-portal/wiki/27.10.16:-Abstracts-and-Quick-Actions)
## [21.10.2016: Exploring teams in Role Base Action Control (RBAC)] (https://github.com/yldio/joyent-portal/wiki/21.10.16:-Adding-teams-to-Role-Back-Action-Control-(RBAC))
## [13.10.2016: What might go on the dashboard?] (https://github.com/yldio/joyent-portal/wiki/13.10.16:-What-might-go-on-the-dashboards%3F)
For older meetings please view: https://github.com/yldio/joyent-portal/projects/1

76
Persona-1:-Daniel-(The-Cautious-Traditionalist).md

@ -1,76 +0,0 @@
Persona1_Dev_Daniel
Daniel - The Cautious Traditionalist
Experience: Senior
Specialisation: Backend
CLI-Centric ‘traditional’ backend developer who prefers to do everything in the CLI (unless there are some useful visual representation).
Spends time in the log checking what has been going on, sometimes just for fun… Also an avid reader of the activity log - who has done what when?
Needs: Clear understanding of what is going on
Clarity of app performance
Clear understanding of why faults appear
Understand how to scale easily
Wants: Simple ways to scale and to take action
Be able to track what has happened and when
Be able to view everything that is public
Worries: Over complicated and unnecessary UI
Intrusive documentation on things he already knows
Difficulties to see issues that have occurred
We should (Our opportunity):
Give contextual nudges to explore platform further
Give non-intrusive indications of alternative and easier ways to complete his tasks
Scenario:
Dan receives an email notification about overuse on an instance and he wants to go and check this out and then take the appropriate action; he decides to SCALE.
As he does this, the platform educates him about what is going on and also informs him about other things he can do, such as how to set up auto scaling and other actions.
Flow:
Action
View (Screens)
Receives a notification about an issue e.g. overutilization.
Email
Opens link attached to notification
Project Landing - Instance List
Optional:
Switches to a service view
Project Landing - Grouped by service
Views a list of instances and sees the one (or more) have issues
Project Landing - Instance list
Click on quick actions to go to scale process
Project Landing - Quick Actions revealed
Clicks effected instance quick action to scale
Project Landing - Scale Instance Lightbox
Add new instance, status change of instance
Project landing - showing instances being created / status change
Optional:
Toggle Service view to see infrastructure connections
Project landing - Grouped by Service or Topology view
(Text needs to be edited in wireframes)
Checks to see if new instances is finished and whether everything is working OK.
Project landing
(Instance needs to be edited in wireframes)
Monitor Instances from a glance
Project landing
(Instance needs to be edited in wireframes)
Visuals of journey (screenflow):
Pdf link:
TBC
Marvel App link:
TBC

98
Persona-2:-Jorge-(The-Aware-Explorer).md

@ -1,98 +0,0 @@
Persona2_Dev_Jorge
1
Jorge - The Aware Explorer
Experience: Mid level
Specialisation: Fullstack
UI-”to begin with” developer (onboards using the UI) “of now” - actively tracks new technological trends, and is interested in learning how to use them and, as such has some container experience, though not much. Went from frontend to backend.
Could easily be the one to bring a new tool to the company he is long-term freelancing for.
Mainly uses the CLI, but if it proves too much trouble, he will pop back into the UI every now and then.
Needs: Quick and straightforward setup
Clear overview of what is going on - mental model of App
Easily do rollbacks and updates (and take other actions)
Wants: Be able to easily test new Code
Be challenged and learn new things
Worries: Over complicated and unnecessary UI
Not being able to quickly pick up how to use new tools
Inconsistent support-documentation and information
Boring and dull new technologies
We should (Our opportunity):
Give contextual, consistent and intelligent education
Give non-intrusive indications of alternative and easier ways to complete his tasks
Give clear signs on how to explore further
Show what happens when trying something new out
“Open up and unwrap” the tool in stages to keep it interesting
Scenario:
Jorge hears about Joyent through word of mouth and decides to check it out. He signs up and plays around with the Educational Dummy Project; decides to try out ROLLBACK
Flow:
Action
View
Register and Signs Up with an email address and no Two Factor Auth
Sign Up Process (need to add GitLab)
Skips billing details
Sign Up Process
Adds SSH Key
Sign Up Process
Finishes sign up and goes to being logged in
Individual User Dashboard, with prompts to create Orgs, Projects etc
(Tweak of organisation dashboard and add demo project feature)
Opt 1: Creates Own Project
Opt 2: Takes a walk through of demo project (View Only)
Chooses Opt 2.
Default Demo Project page view (topology of services), with all services running healthy
(Use Wordpress wireframes but change status or services, icons etc)
Toggles between project service views:
Topology
List Services
List Instances
Project Landing page in three view options
(Most components are already there but need to be copied to correct screens and tweaked)
Reads micro copy that suggests to create a issue with the service
Clicks “create issue” CTA
Rollbacks a service (a scenario of why this might be needed is presented using an educational component)
Select a version, confirm selection
(Components need to match WordPress example)
Rollbacks a project
Is the rollback happening? Did the service rollback? Did the project rollback? Did it help? How have the metrics been effected?
Project Landing Page with progress taking place, then the metrics from the changed “thing”
Visuals of journey (screenflow):
Pdf link:
https://drive.google.com/drive/folders/0B3yOoMWyvxlAT1JkZE1CLVV2aEE?usp=sharing
Marvel App link:
TBC

147
Persona-3:-Nicola-(The-Experienced-Early-Adopter).md

@ -1,147 +0,0 @@
**Persona3_Dev/CTO_Nicola**
**Nicola**** - The Experienced Early Adopter**
Experience: Very senior / CTO
Specialisation: Fullstack, DevOps
An early adopter of anything and everything sort of type, who is looking to the future of cloud and container services with genuine excitement.
Has worked with VMware (Dell), AWS, Google Cloud Platform and everything else under the sun.
As comfortable in operations as in development, she is sometimes referred to as a Production Engineer.
Though very comfortable around the CLI, she prefers to manage the cloud using UI, as long as it is good - it adds ease and comfort to her work, and she is use to it.
Regularly deals with project management, billing, access and permissions for staff over multiple projects.
Oversees a team of 12
Needs: Be confident that "this is a good, stable and
reliable tool"
Confidence in her cloud provider as a company
Good, clear and useful UI
Build a mental map of an application
Clear and easy to understand platform-architecture
Easy permissions and access management
Manage billing easily
Wants: Quick and easy onboarding
Easy "house keeping" and admin
Clear understanding of costs
Being able to see things as a "human"
Worries: Complicated sign up process
Difficult onboarding for her team members
Over complicated and unnecessary UI
Not knowing when something has gone wrong
Difficulties to take the right actions
We should (Our opportunity):
* Help her gain confidence in the tool and in Joyent
* Allow her to easily build and expand the infrastructure
* Make RBac as simple and intuitive as possible
* Help her to onboard and educate her team
* Make sure that her time on the platform feels like time well spent - customer experience and communication
* Give clear indications of running costs
**Scenario:**
Nicola spends a lot of time on Joyent and has the website saved in bookmarks, from where normally starts. Today she needs to ADD a new PROJECT with separate BILLING INFO for an existing Organisation. She pushes the project from her local machine and sees her 5 SERVICES scale in her selected DATA CENTRE. Once the project is set up, she adjusts what METRICS to observe and the parameters / conditions for those..
Finally she ADDS and INVITES PEOPLE to the project.
**Flow: **
<table>
<tr>
<td>Action</td>
<td>View</td>
</tr>
<tr>
<td>Finds joyent in her bookmarks</td>
<td>Screenshot of chrome bookmark bar</td>
</tr>
<tr>
<td>Lands on her page</td>
<td>Landing page on personal "tab" with some projects and organisations prefilled</td>
</tr>
<tr>
<td>Selects “Bi$ Tech” in tabs section to view organisation</td>
<td>Landing page on organisation “tab” with a list of projects
(Change labels, text, companies etc)</td>
</tr>
<tr>
<td>Creates a new project</td>
<td>New Project form (Name, billing card, optionally add people)</td>
</tr>
<tr>
<td>Create a service
</td>
<td>New Service form (add 1 or many, chose Data Center)</td>
</tr>
<tr>
<td>Service created</td>
<td>Project page with topology of services</td>
</tr>
<tr>
<td>Selects a single service’s metrics</td>
<td>Metrics page - default metrics (e.g. CPU, Memory, Latency) with “add more” CTA displayed</td>
</tr>
<tr>
<td>Adds new metrics</td>
<td>Metrics Page - has additional metrics on screen</td>
</tr>
<tr>
<td>Wants to add people, allocate rolls and send invites</td>
<td>Manage People and Teams </td>
</tr>
<tr>
<td>Create a team</td>
<td>Manage People and Teams</td>
</tr>
<tr>
<td>Look at newly created project</td>
<td>Project Landing Page</td>
</tr>
</table>
**Visuals of journey (screenflow): **
Pdf link:
TBC
Marvel App link:
TBC

114
Persona-4:-Jim-(The-Observing-Auditor).md

@ -1,114 +0,0 @@
Persona4_Acc/Sec_Jim
Jim - The Observing Auditor
Experience: Senior
Specialisation: Data Analyst
A data analyst who doesn’t provision any instances or has much “hands on” interaction, but spends a lot of time on the platform ‘observing things’ - he is more of an audit user; he logs on to pull usage and billing data mostly, but also does has account management access and responsibilities, such as billing and occasionally team members and people management.
Needs: To be notified when costs are spiralling
Clear understanding of costs and billing
Easily be able to change pay details
Easy permissions and access management
Easy “house keeping” and admin
View resources by policy - “What's publicly exposed on the internet?”
Wants: Raise questions about data and point it at the right
person
To be able to understand the platform-architecture
Understand what is exposed where
To understand if a user caused a failure
Worries: Not being able to quickly pick up how to use new
tools
Not knowing when something has gone wrong
Complicated pricing structures
Unclear and complicated UI
We should (Our opportunity):
Help him to quickly get his head around the platform
Allow him to easily see and pull the data that he is after
Give clear indications of running costs
Allow him to easily manage billing
Make sure that his time on the platform feels like time well spent - good customer experience, assistance and communication
Make sure he gains confidence in the tool and in Joyent
Scenario:
Jim receives his usual monthly report/ review via email. He follows the link in the email to check that all is ok. Once on the PROJECT LIST, he notices that one of the Projects in TESTING environment has a much higher monthly cost than the other. He believes this is something that ought to be pointed out and raised to someone who can look into it.
Not too sure how to this, he opens “Support and Learn, where he reads about Flags.
He decides to RAISE A FLAG about this to Nicola.
Flow:
Action
View
Receives a monthly report via email
Email
Clicks on email link
Email
Goes to the organisation dashboard described in email
Organisation dashboard (lists projects with price/hour and shows changes to monthly spend)
Views (at least) three projects:
Production Price OK,
Test 1 Price OK,
Test 2 Price High
Organisation landing page
(Use what we have but tweak)
Why is one testing very high?
Project landing page
Open project
Project Landing Page
(Change values to suit “Testing” project and name)
Checks the price
Project Landing Page - maybe more detailed price section
Flags price in quick actions - now someone else job
Project Landing Page - quick actions opened and flag placed on project
(Potential item in quick action???)
Visuals of journey (screenflow):
Pdf link:
TBC
Marvel App link:
TBC
Updated step by step journey:
Jim’s narrative
- Receives an email invoice
-Clicks on the Organisation link (BizTech)
- Lands on Org dashboard - 4 projects
- p1 in testing
- p2 in production
- p3 in testing
- p4 in production
- changes “cost per day” to “per month”
- Thinks p1 looks a bit pricey for testing only
- opens each project to compare what is there
- notices that p1 in testing might have too many instances for testing - What to do??
- opens “Support and Learn” for help
- reads about “Flags”
- Creates a flag and sends to Nicola - “Do we need all these instances here?"
- closes “Support and Learn
- Flag sits on the dashboard “Raised bu Jim to Nicola…”
AJ’s notes on video:
Not convinced that the ‘Support and Learn’ is implemented correctly. Better to have tooltips than a huge amount of text.. (possibly)

19
Prototypes.md

@ -1,19 +0,0 @@
* Sign up - https://marvelapp.com/1d5902h
* Creating an organisation - https://marvelapp.com/1h8e5i5
* Managing tabs - https://marvelapp.com/4jgd2he
* Creating a new project - https://marvelapp.com/1h8gbd3
* Importing services vs creating instances - https://marvelapp.com/4jgiafh
* Topology and list view of services. List of instances - https://marvelapp.com/29i96g1
* Scaling, Deployment Queue and Project feed - https://marvelapp.com/1d5f3dg
* Service rollback - https://marvelapp.com/22fjg1g
* Allow people to configure services through the manifest file [#167] (https://github.com/yldio/joyent-portal/issues/167): https://marvelapp.com/project/1697795/
* Allow people to add services [#169] (https://github.com/yldio/joyent-portal/issues/169): https://marvelapp.com/ej9b136/screen/24489183

13
Research.md

@ -1,13 +0,0 @@
General background on Joyent & Key Terms: https://docs.google.com/a/make-us-proud.com/document/d/1Gjr23i_2TaJohyfeBeMhXKNtK2CJcMV0YGVf9dhB0mU/edit?usp=sharing
Card Sort: https://github.com/yldio/joyent-portal/issues/20 & https://github.com/yldio/joyent-portal/issues/61 & https://github.com/yldio/joyent-portal/issues/58
Competitor Analysis: https://docs.google.com/document/d/1rcboKdJpWnnhjOCBtftcXP-TtUvAr2CYFKlTD-eExPo/edit#heading=h.3tbhoqnh26ei & https://github.com/yldio/joyent-portal/issues/3
Thoughts on current Joyent platform: https://docs.google.com/document/d/1ztKgwjViGCC0hb8fJGqWKtrsvA26rOIwbEnq1e5JfBs/edit?usp=sharing
Object Map: https://drive.google.com/file/d/0B1oWObk56wa5T1BlTVl6a0JSQkU/view?usp=sharing and then updated: https://drive.google.com/file/d/0B1oWObk56wa5ejl1ZEx2d1BNTnM/view?usp=sharing
Learn about available container monitoring capabilities (thresholds, trends, alerts etc): https://docs.google.com/a/make-us-proud.com/document/d/1M_lDFzTZSZ-dnP2Z3a8EnoC77qwGZI9zI-ScmEoEibs/edit?usp=sharing
PDF Doc: https://makeusproud.slack.com/files/hana/F3YLD463T/ifw_dd_2016_public_cloud_megaguide.pdf

8
Staging-Links.md

@ -1,8 +0,0 @@
Here you can find all the staging links for diverse projects we are working on:
* [UI Toolkit](https://joyent-ui-toolkit.now.sh)
* Package selection variations:
* [Just Sliders](https://create-instance-prototype-no-groups.now.sh/)
* [Just Package Type Buttons](https://create-instance-prototype-no-sliders.now.sh/)
* [Sliders on top of package buttons](https://create-instance-prototype-sliders-top.now.sh)
* [Package types on top of sliders](https://create-instance-prototype.now.sh/)

8
User-Testing.md

@ -1,8 +0,0 @@
**05.01.17: Wireframe iterations based on feedback:**
https://docs.google.com/document/d/1ihUNjqgTzXZlXkwIObUDIE7ZKTCrY_QNCWiuDTLQZpg/edit
**User testing documention:**
https://drive.google.com/drive/folders/0B03uff53G5KYUGZWS21yRnFnQ00?usp=sharing
**User feedback goes in this document:**
https://docs.google.com/a/make-us-proud.com/spreadsheets/d/1V_qccL1KIybpbVsU19ZWMCacOAG_qSJQm95YRBhtP1I/edit?usp=sharing

5
_Sidebar.md

@ -1,5 +0,0 @@
**Quick links:** <br/>
[Home](https://github.com/yldio/joyent-portal/wiki) <br/>
[Meetings](https://github.com/yldio/joyent-portal/wiki/Meetings) <br/>
[Research](https://github.com/yldio/joyent-portal/wiki/Research) <br/>
[Staging Links](https://github.com/yldio/joyent-portal/wiki/Staging-Links) <br/>