Website Updates

I think Jinho made some screen capture videos using the app on his phone.I was thinking it’d be cool to make one of scanning an animated QR code (which I can make), @Jinho hit me up if you’re down.

I’ll make some icon images for messenger/wallet/browser over the weekend, unless anyone else wants a crack at it.

Looks like you’re planning to put the text in solid boxes instead of transparent ones, correct?

1 Like

Thank you for letting me know that. It would be awesome if the videos are used for newcomers anywhere!

1 Like

Great Progress from @ivomynttinen on the web designs. Layouts and general style are really coming together as seen in the latest mockups here

General Feedback:

  • I still need to have a deeper review of all copy on site. We will also need someone from tech team to review, validate, or edit copy. This all needs to be 100% technically accurate.
  • Assets to be reviewed again. With layouts nearly complete, we will need to produce final assets. Perhaps @Ned we can have a chat through some of this?
  • Security Page: We should leave some space to show “account creation”. I want people to really understand that security benefits of creating an account which is not tied to any third party (email, phone, etc. @petty please review when you have a chance. We can also start to create the best practice guides on HackMD so we can drive people there.
  • @ivomynttinen - im cool with the latest Get involved content. Lets start designing the pages.


  • This is an open discussion and I will need someone to help with this. Someone who will be responsible for documentation writing, maintenance, and structure.
  • We currently use Hexo across all our docs sites. @ivomynttinen has suggested we use something like Kirby as it is easier to manage. Find his breakdown below. I just want to ensure we are using something that is open source, easily editable by anyone, provides the right level of structure we need and people are generally comfortable using it.
  • We will also need to figure out a general structure for the docs site. Will we want to merge all docs together at some point such as Keycard docs, embark docs, status docs…i tend think we should keep them separate but im not a dev so not suited to make that call. Stripe does a really nice job of listing out all their product docs in a super easy to navigate manner.
  • see the WIP designs from Ivo in the link above.
  • Anyone willing to help me with this? Docs is such an important part of onboarding new developers which is something we will be trying very hard to do over next few months (cc @j12b)


Next Steps

  • Make decision on docs approach
  • start to design out Contribution / Get Involved pages (cc @Hutch & @j12b)
  • Think through final assets (@Ned)
  • Design blog (re-skin of ghost)
1 Like

General comments:

  • Really like the new style.
  • Happy to help with copy review, if needed. One thing that jumps out: under get involved: it should read “open positions” not “open position”.
  • Given the impact that “trending repos” can have in driving new contribution, have we considered a CTA to “star our repo”? This could sit either in the relevant contribute section or developer docs section…

Re docs in particular: By default, I’d rather we keep the current setup as it’s the first one that devs actually use, which is the most important thing about docs. This is after perhaps 5 different docs stacks, so it’s not the first time we’ve been down this rabbit hole. The simplicity of the setup is also an asset, e.g. that it isn’t dynamic and require some external server setup.

It also does provide ‘user management and permissions’ and some form of ‘admin panel’ (yaml/pull requests) by outsourcing this decision to git and Github. This means we get all the security/workflow benefits of Github.

I don’t think having to write markdown is a very strong argument, since (a) most users are devs (b) markdown is super easy to use and preview for anyone.

As to asset management and quality of multi language support / search I don’t have any specific insight, but it either seems solvable or not like a deal breaker to me.

Regarding owner of docs, I think this should be the responsibility of each (major) swarm. If we want to make sure they have a certain polish (though some doc is better than zero), we can introduce QA/copy as part of PR flow for new docs.

1 Like

Agreed re:docs. An added benefit of Github docs is the peer-review and outside-contributor aspect which is tremendously useful in some contexts, not to mention the fact that you basically get an easy-to-consume versioned database of documentation that you can then easily render in any kind of front end by just pulling from Github, rather than depends on a CMS’ preferred format.

Thanks for the feedback guys. I hear you and if the docs are currently working, then lets not change it (especially if you have already this discussion). Once again, Im not a developer so leaning on your input for thee types of things. We will move forward with Hexo and maintain existing structure, simply re-skin.

@ivomynttinen - thanks for latest round of designs - App Download & Get Involved

App Download - This page needs to be way more utilitarian. CTA’s need to be above the fold and as prominent as possible. Design is far less important for these pages as they will serve as landing pages for campaigns and need to be optimized for conversion. Check out the Whatsapp Download Page

Get Involved - I prefer to have individual pages for each section. It will be easier to scale the content on these pages and also drive direct traffic from social campaigns.

Get Involved Landing Page:

  • can we introduce a consistent “sub nav” across the three pages. Looks like you have introduced it on the sub pages. Also I think we need to make the CTA’s more prominent.
  • These pages need to be super utilitarian and have clear and prominent CTA’s. Maybe we bring the 3 boxes below up above the fold
  • I also need to re-think the exact content of the boxes. Looks like too much copy and we need another CTA for each for more actionable steps (i.e. direct to Github for Devs)


  • After seeing this in layout, we need to group the content a bit more. For example, the primary goal of this page should be to push people into Github. We should group content that drives into github (i.e. beginner issues, status-react, status-go, etc). I need to restructure this. Sorry

Educate: Same as Development. I need to group the content to make the information a bit easier to understand and more actionable

Groups - this looks nice.

Chat tomorrow

1 Like

@ivomynttinen - i like the footer and mobile nav. The new app download page looks great.

I also really like the “nav” on the get involved section. How do you foresee this translating to mobile? Also - the new developer layout looks really nice. I really like it and will start refining copy now that we have layout down. Nice work

@j12b have a look at the latest “Get Involved - Developer Page” design.

Priority for this page is to drive people into Github. IMO this page should not need to go into too much detail about the repo’s themselves or the tech (if someone has made it here they are likely familiar) and instead the GitHub readme should provide this level of info. wdyt?

For the “Open Issues” Section - how do you feel about this layout?

We can play with CTA’s on the page and see what performs better. (i.e. “View the repo” vs “Star the repo”)

@Hutch - take a look at the “Get Involved” Sections and please leave any feedback here. Def want your eyes on this. I think the “Commnuity Group” sections will be cool and we can launch with the Ambassadors group. We can set up a public channel and encourage ambassadors and those who want to become - join the channel.

Next Step:

  • Finalize copy
  • Create final assets

Homepage, Features, About Pages nearly complete. Just need final UI assets. Designs here

Security Page - being reformatted to account for more content and ability to add/remove more content more easily. A simple list of security features linking off to editable hackmd docs.

Contribution portal - @PascalPrecht is weighing in on the developer portal and it is currently being re-structured to present onboarding mechanisms in a cleaner/simple manner. Have a look at the proposed portal wireframe here (feedback appreciated). Some notes on developer contribution page:

Designed for 3 audiences:

  • Contributors - People that actually want to help working on the Status app. These people need guidance on how to set everything up locally so they can work on stuff. This includes running the app locally, running tests, troubleshooting etc. They also need to know if there are any contributing guidelines they have to follow. This includes commit message conventions, code styles etc.

  • Extension Developers - This group of people actually wants to use Status as a platform and build something on top of it. Depending on what APIs Status has to offer here in terms of being a platform dictates what content needs to be created here. Either way it should be discussed what is an “extension”, what comes with an extension, how do I build an extension, what can I do with an extension (and what not) etc. So we probably want to have some guides on this and on top of that an API reference.

  • Tool/Ecosystem Developers - Considering that there’s e.g. a status.js library, there could be a target group that actually builds other tools using those libraries that Status happens to use itself. A good example of this is the web client, or StatusX built by Iuri & Co. People that want to build their own tools are neither contributing to the App, nor are they building extensions. But they might end up building their own Status app with available libraries

@Hutch, @Warsoverjohn1, @daoking, @BrianXV - would love your thoughts on the Educators contribution portal. This page is intended to be a hub for all resources someone would need to start educating others on status. Wire also here. Maybe we can collect some feedback and thoughts on what the ambassadors would like/need in this page

Phase 2:

  • Complete contribution portals
  • Research Page
  • SNT Utilitity Page

Great sounds good to me, will review this ASAP and give feedback this week; also pinging @yalu @tbenr @tomnash and @krisc who are heading the Dev Rel / educational parts of the ambassadors so far and doing some really great work.


I just registered here in discuss.


@jonathan I’m speechless, I have nothing meaningful to contribute, the site is everything we need exactly as we need it. Seriously, great job to everyone involved.

For contributing, I imagine that the progression for alot of developers new to clojure will probably want to work on extensions then to status-react, but that assumes we get beef up our extension support.

I imagine in the future we’ll want to make another, seperate web property after this which is more about the overall Status Network, which will show how Keycard, Status Point of Sales, Payment Network, App, token economy & community projects all work together.


@jonathan I love the Information Architecture. It is very sound and sensible. I can see how Contribution portal will be a big step up from what exists right now.

Having said that, it will depend more on the quality of content as well, and we can do well on it as core-devs and contributors come together.

I am barely starting to jump into contributing seriously, and from that perspective, I would love to see more effort put on having more docs like these:

Question: DApp developers come under Tool/Ecosystem Developers? or 4th category of audiences?

1 Like

@jarradhope @yalu thanks so much for the feedback guys.

I completely agree that the success of this portal is contingent on the content that support it. I feel once we have the base in place and the resources/guidance needed for early contribution, we can actually lean on the community to build out the content itself. A really great example of community tutorials is from Digital Ocean

In terms of contributor progress - I agree with you as well. People will have different paths and and different goals. So the aim is to get this first iteration up asap (with as much easily available info/resources) and then monitor and collect feedback. We can then let this evolve as the community sees fit.

@yalu - my thinking is that DApp developers will come under Tool/Ecosystem devs. We may want to break this out later on and also play with the semantics so it is a bit more all encompassing.


-Hutch @yalu @jonathan great to be here and be able to contribute.

my cent:
contributor documentation and extension developers sections have different audience and also different edn\clojure\reagent knowledge level.

So for the extension developers section, seeing it as an entry-point for novice developers who don’t know edn\clojure at all, info\docs should follow a “learn by examples” path. Starting from simple examples to more complex ones, novice developer should be able via copy\paste to create something that works. (i see it integrated with the revisioned extension development UX which we are going to start discussing). The API reference must be there but should not be the first thing the user see.


@jonathan This looks really awesome. Couple of notes:

  • Did we go for “Contribute” versus “Get Involved” as the section heading, or is that still TBD? I don’t have strong views either way, but would be interesting to see how the 2 perform.

  • On the main Contribute page, could we get a “We’re hiring” box or link that points to our open positions/jobs section (I have a to-do note to revise the content)? Maybe positioned below the “top contributors” section? I think anyone looking for a job would naturally look for it here (i.e. in Contribute/Get Involved and/or “About Us”. Given low volume of anticipated hiring it doesn’t need to be too prominent, and should be subjugated to non-salaried contribution.

  • On the “development” sub page, I would even separate the “Install Status and get set up” and “Open Issues” sections - perhaps into different sections/boxes to really make the “Open Issues” stand out.

  • re: Get In Touch: I feel strongly we need to provide an alternative to the 3 listed Status channels. I get we want potential contributors to download the app and dogfood but I also think it would welcoming (and remove barriers to entry) to at least provide another option to contact us - whether that’s traditional email ([email protected]) or something else.

The wireframes look good and well organized!

Let me share some more opinions with you.


  1. In my opinion, the pure black color on the website looks a little strong. What do you think of using less stronger colors? It would look less forceful if we tone down the black color or use blue color series.

  2. I think some components have the same or similar colors side by side, which makes images or text somewhat ambiguous to look. I put three examples.

1: the smartphones and black background have similar black colors. I guess a blue background would make the smartphones more conspicuous.


2: The dark grey box(Mac, Windows or Linux) and the footer(Ready to get started with Status?) have similar colors so it looks a little unstable personally.


3: Similar case, grey and black are located side by side.


  1. Dynamic content
    I really love how the information is structured. But I found that everything is text or images. What do you think of utilizing our video assets like the tutorial videos or so? People tend to be more interested in something that moves. To give newcomers stronger first impressions, I think we need to add more video content on the website. Some proposed examples are
  • What is ENS? Simplify your Ethereum hash code!

  • Do you want to make use of a third-party program? Test out the extensions!

  • Status beta video or a feature video?

The video content will be effective on the features page in particular.

  1. Media assets
    From my experience, It is common to check out some media assets(articles, third-party content, etc) on a website to get more objective, promotional information. This idea needs someone to manage(select and upload) the media assets though.

  2. Less text on the homepage
    Too much information on the first page could make tech-newbie visitors confused. If the website is planning to focus more on the general public, a simpler first impression would make more sense for them.

Considering these wireframes are the drafts, it is really awesome! Let me take a look at the documentation side from now on.

Thanks for the feedback guys. Some responses here:


  • we have opted for “Get Involved” as it seems like a more active way to support rather than contribute. My concern at the moment, is that it is fairly similar to “Get Status” at first glance. This is something I would ideally like to test but will not be able to without any sort of GA. Perhaps down the line we can use something like web optimizer to test different CTA’s/Imagery etc
  • Contribute page is still in active design. We can 100% add a CTA for open positions.
  • Great point on open issues - once again, this is active design and we are still playing with UX.
  • Adding an option for email contact is easy enough. What are your thoughts on gitter? I hate to add another channel just fr the sake of it (especially if our team is all in Status).


  • Great feedback and thank you. The color is intentional. The black and white color palette is somehting that will be used across all channels and campaigns. It plays into the concept of “security and privacy” and also the theme of “binaries” which are present through the application (sender/receiver, you/me, read/write, public/private). I agree it may not be as bright and welcoming as colorful illustrations, but this is part of the point - to instill trust (from a visual perspective) that this is a secure application. We will also iterate on design to intrduce more color elements and the easiest way to do this is by having a simple (somewhat agnostic) design system from the start.
  • The black/grey color pallets pass all readability tests and this was a design decision. If we find it is not working, we can update.
  • Video content - I totally agree and this is something we are exploring (especially in the features page). This content all needs to be produced though - espeically if it is to live on our website and showcase the product itself. I propose - we use static assets for now and then we can put out a brief for all the content that we need to produce and update in phase
  • homepage content - I really dont feel there is is too much text on the homepage. This has already been cut back drastically. I feel the opposite in that the homepage of most blockchain websites all leverage fluffy marketing content with loads of buzzwords that make no sense and lack any sort of differentiation. This layout is intended to showcase the product features and position them in a secure manner as well as drive people in to contribute.

I trust that you understand and know the Korean community far better than I. Perhaps in phase 2 we can start to optimize this for that community.

1 Like

@jonathan What is the expected impact on the existing documentation in the current website? Will the existing syntax be supported?

the plan for documentation is simply to re-skin with new header/nav and footer.

We will not be changing anything else (syntax, content, etc). I am not the right person to be updating docs or making decisions on how documentation should be created.

1 Like