InVision high fidelity prototype, content and Balsamiq mockup wireframe for the website: v1

[snehasi]

In context with the discussion and current website framework.

[GeorgLink]

relates to #2

[snehasi]

@GeorgLink - Thanks for the feedback. Working on it.

[GeorgLink]

@snehasi whow you are fast. The wireframe pointing in the right direction now.

[snehasi]

@GeorgLink - Thanks. I have to work on the documentation to make content for the website. Can you point me to some issues in bugmark/docs where I can begin? Can I also add some on my own?

[GeorgLink]

A good overview of the core bugmark features are visible through the API design (https://github.com/bugmark/bmx_api_ruby)

If you want to understand the general workflow of how the market is designed to work, the regression tests (executing the commands and checking the results to make sure nothing breaks between builds) is a good place to start. (e.g., https://github.com/bugmark/bmx_cl_ruby/blob/master/spec/contract_resolve_fixed_spec.rb)

[GeorgLink]

We also have a repository where the documentation can be compiled, and there you can contribute for sure: https://github.com/bugmark/bugmark_docs

More documentation lives in the wiki: https://github.com/bugmark/bugmark/wiki

[snehasi]

Thanks a lot. Looking into them. Can I merge this PR into the dev branch, if no changes are required?

[GeorgLink]

1) Let's wait for feedback from others. 2) As you look at the documentation, maybe you can refine the wireframe for the startpage add wireframes for subpages. - I view pull requests as a place to do work and get consensus before a refined version gets merged.

[andyl]

@snehasi - had a look at the wireframe PNG - looks fine to me. I liked the web-dev blog post quite a lot. I'd like to do all the steps of your work process, but I think we'll do things in a different order.

Phase 1 - Dry Run of Tooling and Work Process 1) quick wireframe [DONE] 2) prototype a look and feel, emulating bootstrap in Invision 3) knock out a real static site using Jekyll - test for responsiveness

At this point we know how the tooling works and all have a shared experience of the UI.

Phase 2 - Make it So 1) Do a lightweight envisioning process per your blog post 2) Wireframe it 3) Build it

The website messaging: much of the docco we have is "aspirational" written in a time when we were trying to envision a game-changing paradigm. That is done, and now our mission is to make Bugmark simple and actionable for the commoner. In doing so, I'd like to define our target audience and value proposition very narrowly: applications developers who use our API and CLI. That's it. Keywords for the first version of the static website: simple and practical. Key performance metric: time that it takes a developer from first exposure to the website to first successful interaction with the bugmark exchange thru our CLI/API. Proposed Tagline - something like "Bugmark is the fastest way to build Issue Futures into your App"

Make sense?

Re: merge to dev protocol - how about a rule where each of us issues a PR from WIP to dev, and any of us can merge someone else's PR. That gives an opportunity for periodic discussion/review/knowledge transfer.

@snehasi and @GeorgLink WDYT?

[snehasi]

@andyl Thanks for the feedback. Yeah, this task plan looks excellent to me. Working on it. For the merge to dev protocol, that would be good. Reviews from more people would be nicer.

[andyl]

@snehasi please note that @cynthiapereira has made nice progress on a Jekyll layout in #3. When it's time to do the Jekyll prototyping please coordinate & use her layout and/or let her do that implementation.

[snehasi]

@andyl - Great. I will coordinate with @cynthiapereira and use her Jekyll layout, as soon as I'm done with the InVision high fidelity prototypes.

[cpswsg]

@snehasi If you don't mind, I would like to make the implementation of your design when you done with the prototype.

[snehasi]

@GeorgLink @andyl @dmarti -

• I've made a video of the InVision prototypes, as sharing it on InVision would need everyone to sign up.

• Instead of a Low-fi prototype, I've made the high fidelity one including design aspects, and the content I could gather and understand from the current documentation and code. It includes use cases and the Bugmark vs other market features we discussed previously.

• I'm still working on the APIs and have left some queries for that in the relevant issues. I'll be finalising the API documentation content as soon as I'm clear about those queries.

@cynthiapereira - Sure, I'm glad you want to use my design. You can go ahead, however, as I'm still working on the APIs part and want to improve the website progressively, I will be making the developer page (there are three pages). :)

Thanks!

[GeorgLink]

Thank you. This looks really good.

[andyl]

@snehasi Thanks for posting the .mov that will get us started. Initial feedback:

• [x] use off-the-shelf bootstrap colors (gray/black/blue/white) no yellow
• [x] change "BugMark" to "Bugmark"

@cynthiapereira - let's see how it looks in HTML!

[snehasi]

@andyl - Sure, I'll change the color scheme to that in the Jekyll site, and fix the typo. Thanks for the feedback.