Proof-of-stake storyboard revisions

[justinsantoro]

minimalize the visual design and correct errors in icon usage.

• correct all icon usage
• remove overlapping icons
• limit # of icons on screen at a time
• space out icons
• meaningful transitions between icons.
• schematic like - minimal detail oriented and clear as possible
• correct scaling between icons + symbols.
• visual grid logic

[justinsantoro]

The first symbol with coins is a somewhat obsolete one, was meant for an older dcrweb release to indicate 21. Mil cap. Didn’t realise it was in the package and I would not use it at all, since we’re avoiding the coin metaphors in general. For clarity write out proof-of-stake or staking and use the ticket instead as that’s the key icon. Re: to comment, i’d also recommend considering Stakey to tell about Staking, but obviously should go with rest of Stakey illustration style then rather than icons.

2. has three items, though mentions two topics. Although first icon is generally for privacy, works there also. Second is roadmap, third is freedom of speech. There’s not a very specific governance one, but the closest is the scales that’s used for dcr constitution.
3. Can check decrediton on boarding clips for a good reference. Same topic is visualised there.
4. That icon indicates a vote. 9) Avoid overlapping and putting them together like that. Reason is that will look cluttered and tacky. The icons by default are meant as stand-alone items representing one single topic. Symbols on the other hand are more complex to represent wider topics. Size-wise those are built on a @ 2x icon grid, so similar proportions could follow. 10) That’s a roadmap icon for DAE, should’t be mixed with staking/network. 12-14) Unclear what’s going on there.

Rule of thumb (e.g. 4/5) rather think about how to animate clever and meaningful transition of one icon into another, or how to integrate them in a creative way rather than just displaying the two or overlapping. That way you don’t have to be too literal which can backfire. Also would avoid having too many icons shown at a time, space them out or have up to 1 or 2 together. Maybe consider using words to emphasise wider topics. Finding a consistent size and space logic, and building a grid for those will help with visual clarity. If the whole animation is based on icons, can be almost schematic like – minimal, detail oriented and as clear as possible

[ta-lind]

I'll drop the feedback here to the latest https://github.com/justinsantoro/video-production/blob/95a7c88c949f73b728d36fbee1f595d7c1f2e312/decredStakeVoting/decredStakeVoting_storyboard.md

Overall the style looks a lot sleeker and organized, that's a good direction to keep moving towards.

A fundamental item to sort out right now is the terminology. As there is not a specific agreement nor clearly established terms to use for describing staking, any tutorials should aim to use the absolute minimal and generic terms imo. Right now though there is use of "stakeholders"; "ticket holder", "Proof-of-stake voters".

For this same reason, the copy in Decrediton has been redacted to stick with only proof-of-stake and staking. I would say that staker is the closest term to miner, though as this is not widely agreed upon, best to stick with a generic term such as participant or participation if written in third person.

• Proof-of-Stake – Staking – Participant in Staking/Staker (?)
• Proof-of-Work – Mining – Miner

Icons:

• Slide 1: The pickaxe represents proof-of-work or mining. So i'm guessing the ticket would be somehow highlighted there to indicate the topic is about staking not mining?
• Slide 2: Chain icon does not represent a blockchain. It's been historically used for paired items.
• Slide 3: "buy tickets" with square could instead be icon of funds (a transaction icon with a circle on it instead of plus/minus) and time/lock also in the scheme somewhere. As the other geometrical bits represent various choices.

I've included an older schematic displaying the higher level voting process. Though it's roughly put and with wrong items, can reference the blockchain and such.

[justinsantoro]

@linnutee here is my latest revision https://github.com/justinsantoro/video-production/blob/97ff29fe90ed835762fb0d6925704583be6b5129/decredStakeVoting/decredStakeVoting_storyboard.md

Slide 1: The pickaxe represents proof-of-work or mining. So i'm guessing the ticket would be somehow highlighted there to indicate the topic is about staking not mining?

Yes, I thought it would be good to briefly show the pickaxe and ticket together to reinforce the hybrid pow/pos.

changes in this revision: I simplified the terminology to just participant as you mentioned, swapped out the chain icon for the correct blockchain one, and added a few more slides.

some questions:

• slide 3: is that the icon you were referring to?
• slide 2-3: Should I just use the icon the shapes are from instead of the shapes themselves?
• slide 4-5: What do you think of the use of logic symbols here? if, >, <

note: slide 7: I talked to lustosa and he informed me that he would be making new mature and voted stakeys, so I put three immature stakeys as placeholders.

Thanks for the help!

[denyszayets]

Hi @justinsantoro thanks for the invitation, I'll be happy to assist you with some feedback too. I'll be off this weekend, but I will follow this issues closely ;) great work so far.

[justinsantoro]

https://github.com/justinsantoro/video-production/blob/19f4e71edfda04a8a7cd73817c62d51a6442a8ce/decredStakeVoting/decredStakeVoting_storyboard.md Having some trouble working in voting on proposals. Also unsure as to best way to introduce color. Open to all suggestions.

Also, here is first go at the motion.

[denyszayets]

Justin this looks good! I like the background for this animation; it keeps you focused on the center of the animation. Right now it seems very technical and details oriented. Introducing colors will be an interesting experiment. I would suggest referring to the newly updated RGB list:

Primary focusing on these three: #2970FF #2DD8A3 #091440

Below is a variety of colors included in our branding:

[justinsantoro]

https://github.com/justinsantoro/video-production/blob/a6811d1a538b5d43806186716a819c6f36cf2721/decredStakeVoting/decredStakeVoting_storyboard.md

Finished out graphics and script for pi section.

Next steps:

• figure out where to use color
• make final visual tweaks (I think shots 4, 10, and 18 could be improved)

[justinsantoro]

@denyszayets Thanks. Technical and detailed is the goal. Just needs to be fleshed out with some color and maybe the blockchain pattern to make it more Decred.

[denyszayets]

Maybe you can make 2-3 variations of that slide with colors, before jumping into the entire list. Are you talking about the blockchain pattern we used on the booth at the conference?

[kyleFirethought]

https://docs.google.com/document/d/1XAKzDOgqr5yDePTv1Sp1zFw6txFoCXUIMNhAlvwBupo/edit?usp=sharing - Observations.

[justinsantoro]

https://github.com/justinsantoro/video-production/blob/e677877bdcb974fbb339430e3bc73226ca1ab845/decredPoS/decredPoS_storyboard.md Here is most recent version.

I addressed the issues brought up by @kyleFirethought and swapped out some of the schematics for scenes. (just descriptions for now)

I left schematic 16, but Im not too thrilled with it. Let me know if anyone has a better Idea for that one..

[kyleFirethought]

Overall some nice improvements but still needs some tightening up.

1. Ticket doesn’t need to move into place, ticket can be made to disappear and reappear into place.
2. See notation***
3. See notation*** Not sure the ROI icon makes sense in this context - Maybe a transactional icon or timer to represent funds being staked.
4. This could be a good ‘use case’ for a darkened background.*
5. No comment
6. No comment*
7. No Comment*
8. This time estimation seems overly generous.
9. Tx fee Exchange icon should be txTax icon or simply tx. Stakepool?**. Ignore *** as the eye is drawn from the centre left into the schematic flow.
10. There needs to be continuity between dcrdocs and any educational material: https://docs.decred.org/mining/proof-of-stake/ - name changes ( in this case: Ticket Pool and VSP ) subject to a Politeia vote and can’t be called by individual contractors as it affects many other repos.*
11. See above^*
12. Block Headers icon correctly used here. (thumbs up)
13. No comment
14. No comment
15. No comment
16. See notation***
17. No comment*
18. User Profile icon should be Proposal icon. Consult Documentation re: network treasury. Development Fund isn’t exactly present in the dcrdocs.
19. No comment*
20. No comment
21. No comment
22. No comment

I guess you’ll need help with this? It might be wise to create two versions of the voice over 1. With the current documentation terms. 2. With terms that could be voted in once Pi is functional on mainnet. In Cyrillic and Latin languages left to right is a common convention and diagrams drawn in contrary to this can appear disorientating and distracting. Other Note: Inconsolatas is being phased out for Source Code Pro.

[justinsantoro]

Thanks for the feedback.

Regarding your (***) notation:

In Cyrillic and Latin languages left to right is a common convention and diagrams drawn in contrary to this can appear disorientating and distracting.

• scene 2 is oriented in that way so that the text 'on-chain decision' reads left to right. Additionally, as described in the action of that scene, the schematic actually builds out left to right, then is connected by the line right to left. The line could even be drawn from left to right with arrows flowing right to left if it really must go left to right. (I'm not sure it really matters so much). My main goal with scene 2 is to associate the blockchain icon with the text 'on-chain' as well as the spoken word to really define that icon for the video. Otherwise it's just 5 rectangles.
• Scene 3's orientation is a consequence of the orientation of 'on-chain decision' in scene2.
• If anyone has a solution to this, please share. I cannot think of one off the top of my head.
• Scene 16 builds left to right as well. It Starts bottom left, goes up and around. It's a cycle. Again, as I've stated before, I think this schematic could be improved, but I have not been able to come up with anything better yet. Would love some suggestions. The main idea here is to show the length of a consensus vote and order of events. Upgrade first -> vote on upgrades -> implement upgrades if approved. The speed of the animation can be used as well to drive the point home that consensus votes happen over a long period of time as compared to block votes which as described in scene 14, is animated to 'cycle' more quickly.

scene 4

• Not sure what you mean by this:

  This could be a good ‘use case’ for a darkened background.

  could you be more specific?

• In response to (*): I can draw these out if you like. I didn't want to spend the time drawing them just in case it turned out to not be an ideal solution. That being said, I don't care too much what it looks like, as long as the information and action is there to get the point across.

scene 8

• You are right. Must have been a typo.

scene 9

• Stakepool?**

  • No mention of stakepool here... the ticket pool (where tickets wait to vote) and stakepools (which cast votes on behalf of stakeholders) are different things. Which brings me to my next point:

Regarding VSP (**):

There needs to be continuity between dcrdocs and any educational material: https://docs.decred.org/mining/proof-of-stake/ - name changes ( in this case: Ticket Pool and VSP ) subject to a Politeia vote and can’t be called by individual contractors as it affects many other repos.

• It's not my intention to 'make the call'. I'm simply attempting to be prepared and as clear as possible. The change from stakepool to VSP has been discussed a few times now. It is also currently being used in the Telegram group. Dave made a clear argument for the change here.
• The suggestion to create two VO's with the old and new term is a good one. My big concern, however, is that spreading the use of a term that in itself is a bad descriptor and that is most likely going to be changed in the near future could end up being very confusing for newcomers.
• This only applies to VSP. I personally prefer network treasury, but will happily go with what is in the docs (development fund I believe?) because they essentially mean the same thing. My concern with using stake pool is that, as Dave pointed out, it is simply confusing and doesn't accurately represent what a stakepool is / does. Using it would require a brief explanation of how a stake pool is different from a mining pool to dispel confusion, where as the term 'Voting Service Provider' can stand on its own. Additionally stakepool is easily confused with the ticket pool as well.
• Another concern I have is that (assuming these videos will be hosted on youtube...) If we have to go back and change the video after it is released, we will have to upload it as a new video and will lose all the gained youtube context around it such as views, likes, comments, etc. Most importantly, any links to the video will become broken (if we delete the video) or outdated (if we keep the video and route viewers to the updated version).
• I understand that this could backfire if, when pi is launched, stakeholders vote to change it to a different term besides VSP. However, I believe using VSP now and having to change it later anyway is still better than spreading stakepool further.

Regarding Font:

• That is Source Code Pro. I've been using it since the beginning. They're very similar. Notice the difference in i.

I will change the noted icons. Again, any suggestions to improve scene 16 schematic (explanation of consensus voting process) are welcome. Maybe we need input from some devs. @raedah

[kyleFirethought]

No worries re: feedback 👍

Transition Style:

By "morph" do you mean cross-dissolve as I imagine this would be no change in the form of already present icons? I'm currently working through the iconset and animating opening animations and loops which should give you some choice in this regard, either transitioning with a simple fade out for time remapping (reverse) where appropriate.

Scene 2 + 3:

I'll send over thoughts re: above scenes when it's not really late.

Scene 4:

could you be more specific?

Inverted Scheme:

In response to the indecision regarding colour palette, an inverted scheme could be used with the wallet outline to signify a change in scene from the 'schematic flow' elements to a 'prototype demonstration'. This would break up the video visually and provide a nice change of scenery.

Icon Replacement:

The whole 'prototype demonstration' is a good idea, however, there are a few options for sure. an animated lock icon and an alert would suffice here. Ultimately it's your call here - if this is the route you want to go down then, by all means, start working on wireframes.

Scene 8

I meant more in regards to the timing of the section in relation to the action presented and V.O present (00:22 seconds). However, the average generally used is 28 days (obviously this is generally longer with a saturated pool).

How long a ticket lives in the system is largely up to chance, but averages 30 days.

A common support requests (as far as I know) is people unaware of the maximum time that a ticket can be Live. Might be worth noting the (~4 months) prior to expiration as it could cause contention within the audience who stake tickets that unfortunately run the whole cycle.

How long a ticket lives in the system is largely up to chance.

It's absolutely up to chance - It's Live in until randomly called, a user can't influence that.

There is nothing in the storyboard about ticket revocation which begs the question:

What happens to my DCR if it's not chosen to vote within the expiry period?

This is a fundamental question that needs answering in the piece so to quell any doubt from prospective network users. https://docs.decred.org/mining/proof-of-stake/

The last thing we need is educational material that poses more questions than it answers.

Scene 9:

No mention of stakepool here... the ticket pool (where tickets wait to vote) and stakepools (which cast votes on behalf of stakeholders) are different things. Which brings me to my next point:

No mention of mempool either 💯* (typo on my part)^ - however, the rough process is described nicely here and too many 'pools' will only confuse. Plus as far as I'm aware there is no iconography attached to mempool.

Regarding VSP:

I understand that this could backfire if, when pi is launched, stakeholders vote to change it to a different term besides VSP. However, I believe using VSP now and having to change it later anyway is still better than spreading stakepool further.

Personally, I don't disagree with you, all those issues raised are very relevant however until the vote takes place on Pi you just can't know for sure what we will go with moving forward with.

Let's say things were to fall in the favour of 'stakepools' that would cause some additional headaches which could have retrospectively been mitigated. Never underestimate the unpredictability and irrationality of voters.

Plus the work to accommodate both terms is negligible is the grand scheme of things. Obviously, this is your call to make from a production standpoint - Proceed with caution.

Service fee:

These pools/providers are not affiliated to Decred and charge a varying fee for their services.

Scene 11:

"So am I rewarded for voting? What happens when a participant's votes are broadcast to the network?"

"Can I spend my ticket funds immediately? Why are my funds still not spendable after my ticket has voted?"

^full ticket lifecycle needs to be explained/represented to avoid a comment section crammed with these support examples. The economic incentive to participate in PoS is by design.

Cue: chestOpening.gif

Regarding Network Treasury:

I personally prefer network treasury, but will happily go with what is in the docs (development fund I believe?)

There is no discrimination over the term is this regard outlined in dcrdocs.. You have free reign here (within reason).

Scene 16:

Some inspiration: https://voting.decred.org/ - given the iconset now available this shouldn't be hard to replicate or borrow elements. The current schematic needs a different layout, specifically the timer needs to be placed elsewhere and there is no iconography representing blockchain - on-chain voting being a keep USP for Decred's network and the initial point made.

Font:

Noice, just a gentle reminder.

Open / Closed Captioning:

No idea if this has been discussed but what this the direction of this project in this respect?

Documentation Copy: I would recommend @raedah and @jholdstock comb through this V.O and offer an independent review as on my second reading there seem to be some fundamental holes to rectify.

Anywho time to call it a day I think - Let me know if anything else needs further explanation.

[justinsantoro]

Just wanted to outline my reasoning behind some of this stuff. 👍

Seems like we are on the same page.

transition: Yea 'morph' probably isn't a good word. couldn't really think of anything else. I just wanted a way to connect related schematics. Could be simple fade out or time remapping as you mentioned. Whatever is simplest. The icons themselves do not need to be changed. Just want to show through the transition that the two schematics are related. However you feel is the best way to achieve that is fine with me.

I really like the idea of using the inverted scheme to seperate from the schematics.

scene 8 ah I see what you mean. Yeah last time @raedah and I went over the script he told me there was new data that it is leaning more towards 30 days.

As far as things not mentioned in the script such as mempool, expired tickets, missed tickets, stakepool fees. These details were all included in earlier drafts and after some discussion with the writers room and @raedah we opted to not include them as they are not explicitly need to know for the average user and/or are relatively rare events. I also recently experimented with including an explanation about solo staking, but again, majority of users who would watch the video and not read the docs as well would not be solo staking so It didnt seem worth the added length to the video. These videos aren't supposed to be a complete alternative to the docs, but a way to get all the main ideas in ideally 3 minutes or less. I plan on directing people to the docs for more detail through youtube cards. Also if we feel we want to include explanations of these details, that could be done in a follow up video which would then be linked to in this video.

VSP: Yeah, im still very undecided, I suppose for now we will plan to use both and make a decision later on in post.

Wireframes: Yeah I think since these things will take place in the wallet the wireframes would be best. Plus I think being as literal as possible would be beneficial. Ill start drawing them out and see if it comes together they way I see it in my head.

[xaur]

looked through rev ea8730d3 of Aug 24:

• 04: "an algorithm designed to keep the total number of live tickets equal to the target size." -- I would use "close to the target size"
• 09: "About every 5 minutes, with the creation of each new block, tickets are randomly selected from the pool." -- maybe specify the amount: "5 tickets are randomly selected.."
• 10: "by their chosen voting service provider for inclusion in the next block." -- I realize this is for casual users, but worth at least briefly mentioning somewhere that anyone can run a VSP for themselves (=> solo)
• 11: "the ticket is revoked and the corresponding funds are unlocked so the participant can try to cast their vote again." -- "try to purchase the ticket (and cast their vote) again"
• 15: "Consensus voting is a two stage process where participants vote for or against the implementation of changes to the Decred network." -- "changes to the Decred network" is too broad, CV only concerns "consensus protocol, the heart/core of Decred network". I understand this is a tradeoff between brevity and accuracy.
• 16: "Once a majority is upgraded, voting is scheduled to begin. Once a majority of nodes have upgraded, voting is scheduled to begin within 3 weeks time." -- duplicate text
• 17: "If less than 75% of votes are yes or no votes, than a revote occurs." -- min quorum is 10%, so "if less than 10%", source: https://docs.decred.org/getting-started/user-guides/agenda-voting/
• 18: "After a participant's vote has been cast and a 12 hour waiting period has elapsed, the funds used to purchase the voted ticket are unlocked" -- the maturity period after vote is another 256 blocks or ~21 hrs https://docs.decred.org/mining/proof-of-stake/
• 19: "Politeia, Decred's public chain-anchored proposal system" -- add "upcoming"

edit: Also 17: "than a revote occurs" -- "then"

[justinsantoro]

@xaur Some good catches. Thanks!

For the record: Mentioning of solo staking was attempted https://github.com/justinsantoro/video-production/commit/2b563687a2d9ebe21e6edc4ffc62dcaa90d6a533 but we decided to leave it out since I couldn't come up with a solution that didn't break up the flow of the script and because those who will solo vote will probably just start with reading the docs anyway so theyre not exactly part of the audience for these videos.

I plan on using youtube cards with links to the docs on topics that are not explicitly covered in the video. The goal isn't so much as to be a complete alternative to the docs but to give a good overview and inspire newcomers to want to dig into the details, which would then require reading the docs. However, even without reading the docs they would still have all the basic information necessary to participate in PoS Voting.

[kyleFirethought]

Okai...

Prior Notations: Mise-en-scene: Alexander MacKendrick has a really good book out called On Film-making (was to go to for me during my College studies) (https://www.amazon.co.uk/Film-making-Introduction-Craft-Director/dp/0571211259). In this book there is a really nice Foreword by Martin Scorsese which provokes the reader to consider why certain shots or decisions regarding Mise-en-scene are implemented, ultimately raising the question – “What does this add to the piece?” from a narrative perspective. I raise this notation because colour is a powerful thing (used responsibly) and these are a few confusing instances re: colour usage prompting me to consider the question: "What is the purpose of this colour? - why is it used in this context?"

Highway Code: Red, Amber and Green have unilateral connotations that inform behaviour. The most common being the Highway Codes of nation states (respectfully). Incorrect usage of these in the context of a technical illustration may cause unnecessary confusion https://www.gov.uk/guidance/the-highway-code/light-signals-controlling-traffic - try to keep a neutral “duotone” colour pallete, primarily blue and grey hues to avoid confusion. Justification here should only be where processes are deliberately staged, if this is the case outline significant colour changes in action or where parity with decrediton elements is sought.

Decrediton parity: It would be bonus at this stage. Usage of the coloured ticket and general colour conventions used throughout the desktop client would help viewers transition from the video to actual wallet usage.

Dcrdocs: There are a few instances where the information stated is factually incorrect. Please align this with the information provided in dcrdocs. I would also recommend reaching out to a dcrdocs contributor to verify the copy and technical drawings prior as reading over some of the copy personally raised a few eyebrows.

Opacity: Highlighting doesn’t need to be revolved around unnecessary colour coding. Simple changes in opacity, will suffice yet retain visual continuity and generally become a lot readable.**

Conclusion: Obviously take these notations with a pinch of salt. If the use of the colour can be by any means justified please correct me. If not overuse of the extended colour pallete can result in overwhelming visual clutter. Realistically I’m currently working to create icons that fall within the “Duotone” style currently present in decrediton Navy/Grey and the Extended ticket state pallete currently implemented in 1.3.0

[2] Nice however the colour Green doesn’t carry any visual significance at this stage so it might be more apt. to use a change in opacity to highlight the PoS icon. This works across both PoS and PoW icons (Where would you highlight green on the PoW icon?) should a PoW video be pursued. [3] see notation - Unnecessary use of colour Red in both Opinions and Block Header icon. Focus is drawn to a binary outcome not the more important process of on-chain decision making. [4] see notation - Colour isn’t necessary to demonstrate the sdif relationship. @xaur is right - The sdif algo is designed to moderate not equalise. Notation change here would be necessary. [5] see notation - Colour adds little in this instance, change in opacity could be a better visual signifier. [6] see notation - No decrediton parity and generally confusing: theoretically the colours should be swapped between unmined and locked as unmined is a ‘pending’ state the ticket goes through before becoming immature or expiring. [7] see notation* - use of Amber is unnecessary. Please consider a small notation of the maximum waiting time, timewise there really isn’t an excuse and it’s a crucial part of how the network functions.

“In case your ticket isn’t selected to vote after 40960 blocks (about 4 months), the system will revoke your ticket and the decred you paid for it (minus fees) will be transferred back into your wallet.”

• Decred Documentation - PoS

[8] see notation. “a ticket is considered immature and must wait about 12 hours” – This is factually incorrect, see dcrdocs PoS documentation. [9] see notation - Green colour coding conflicts with voted ticket state in decrediton. The statement here needs general improvement and doesn’t read particularly well. [10] see notation. This diagram needs peer review recording alignment with dcrdocs. See previous notes as there are concerns not addressed here. [11] see notation. “Where do my funds go on voting” – poof? The piece needs to be aligned with dcrdocs, come-on guys… [13] see notation* & * - The action outlined can be achieved without the use of cliché Green = Go, Red = Stop colour conventions. The use of Amber is unnecessary. [14] see notation. Dcrdoc scrutiny required [13 – 16] [17] “After a participants vote has been cast and a 12 hour waiting period has elapsed, the funds used to purchase the voted ticket are unlocked” – This is factually incorrect, see dcrdocs PoS documentation. decrediton does colour code text, use coloured icons to retain parity with decrediton. This slide may also work better in a linear sequence with the previous voting stages [11]. [18] see notation*. This line needs work – “where anyone can propose new ideas” realistically it’s currency holders. [19] The time range explained in action may be slightly problematic. I’d recommend simulating a full RCI on screen displayed through the same decrediton interface. Deadline is a tad misleading as ultimately there isn’t a rush (as deadline often suggests) as an absolute number of votes will be cast in that given period.

Apologies for any typos or grammatical errors, these notes were put together in a number of interesting settings while in transit. 👍

If you need any point expanded quote it and ping me.

I would recommend looking at the latest RC 1.3.0 to get of how colour is used effectively across decred’s applications. This release will no doubt set the tone for future brand revisions on other platforms.

Broadly agree with the notes by @xaur bar Pi as it's likely that Mainnet will be pretty active once this is created.

@RichardRed0x any scrutiny you can provide on this storyboard would be greatly appreciated as I believe you have better eyes for this. Your help would be appreciated in this regard as in places there is a lack of continuity with dcrdocs.

End of Notes.

@justinsantoro @linnutee

[justinsantoro]

Welcome back kyle,

I've certainly read that book 💯. (if a had 1 DCR for every time a professor uttered "Mise-en-scene"...) I indeed chose those colors for specific reasons. Mainly to differentiate different phases and processes within one graphic. I understand that they are internationally recognized as stop/go/caution but in my opinion to assume that those associations would confuse the audience doesn't give the audience enough credit. (especially in a context so far removed from a traffic system) But in some instances I intended to use these associacions to my advantage. To explain my intentions behind each use of color would be a waste of time right now but just to give two examples:

• scene 2-3: Here I use the colors orange and green to represent votes (green = yes, orange = no) The purchase ticket line is also green since the addition a ticket could also be associated with the color green. These colors will not be continually present on the screen, but more "flash" by as the schematic "cycles"
• scene 8 This graphic is the one that gave me the idea to use orange yellow and green. An unmined ticket is red since it is not yet in the system and can do nothing. An immature ticket is yellow since it is in the middle phase, and a live ticket is green because, well, it's live.

I agree the colors in some of the other schematics dont really have much purpose other than to highlight but im thinking of changing most of those graphics completely. Perhaps we should further discuss the visual style in the issue on the dcrdesign repo and keep this one focused on the information.

Which brings me to the script:

Yes all of your points about the script are valid. While you were gone @raedah and I went through and identified things we wanted to add based off of feedback from @xaur and some devs. Untimately I ended up starting from scratch.

Here is the new version of the script. I would appreciate feedback from everyone here as well as @noahpierau and @Arriu (who I believe is jazzah on slack?) I based this script on the conversation in #documentation. My main goal was to add more information while making it more conversational so it is easier for the voice actor to read. Feel free to tag anyone else you feel should read this.

In other news, we have selected our voice actor. Her name is Erin Setch, she is a pretty well established actor who is the voice of lots of explainer videos for amazon and such. We found her in this cockroachDB video. She is ready to go whenever we are so I would like to finalize the script asap.

Thanks everyone for taking the time to help out!

[ta-lind]

I agree with Kyles points on use of color and sticking to a more common approach around the duo-tone icons. They will perform the best if used with that intent.

Elaborating further on the duo-tones, with reference to this preview:

• Most straight-forward use case is with tonality steps – e.g. 100% and 50% steps as defined in the color schemes.
• With the blue and grey tones, there's more defined inbetween steps than with other colours, so those add the possibility of for example greating more active and less active states (hierarchy plays).
• There is also possibility of using the duo-tone icons on a third color solid bg, though in these instances the colors definitely need to be complimentary and have strong tonality contrast. This generally involves either one of the most lightest or most darkest tones (so things wouldn't get too pop-arty-warholish).
• Having a r/g/b regularily next to greys or details of the icons with several colors is not visually very pleasent.

Meaning-wise the use of traffic light scheme will likely get confusing to the viewers. I see right now there's instances where the meanings of r/g/b stand for one thing and then a different thing elsewhere. I think more appropriate would be finding a scheme or motion design method for simply highlighting the currently narrated item and it's relations to the follow-ups or other nuances where needed.

For example when it comes to UI design, I always prefer an icon instead of only color to indicate meaning. Or then have both (e.g. tx icons). In most instances Decrediton uses blue tones to highlight various interactions. This way we avoid logic conflicts (e.g. positive negatives – successfully deleted something? Or nuanced/neutral items).

As this refers to Decrediton quite heavily, either a mono/grey approach or in some instances (e.g. ticket states) the same color coding makes most sense. Having conflicting colours will be least relevant imo.