UI Pathways

I know I'm repeating myself, so this is really a point of clarification. @mix please take a look and we should liaise re the front-end for Dark Crystal v2 as I want to take on more of this in this iteration (esp since I've not had a chance to do much of the back-end coding and I've been doing more front-end JS recently). I'm not sure if you've started or not working on things, but there's no PR up on patchbay-dark-crystal yet so before we get started I want this to be better planned. In v1 you dove in and I feel like we could have done a better job on planning the UI more. I'm hesitant to jump to building out a UI without thinking it through if it means embedding / accidentally encouraging possible user-errors.

There are 4 pathways which are currently under development or have been developed. I think we should take this approach and keep the Return Shard/s and Forward Shard/s options as far away from eachother in the UI as possible to minimise hitting the wrong button.

Taking the approach I've outlined above and now below minimises this as it forces the person using Dark Crystal to ask themselves what they want when using it at this point in time and take a pathway based on that set of variables.

1 - Home Page and 'Create a new Dark Crystal'

The Home Page doesn't exist in this capacity which simply sets a person on a journey through the application based on the set of choices they have (choose your own adventure!).

The DarkCrystalNew view already exists and doesn't need any work, it simply acts as pathway 1 from the home page.

Views:

• DarkCrystalIndex
  • Effectively the 'Home Page'
• DarkCrystalNew or RitualNew (interchangable as its a one-to-one relation)

Components:

• AreYouSure

2 - 'Return a Shard'

Pathway 2 from the home page. Visting this view you can easily determine if you hold shards for anyone by simply selecting a friend from the dropdown and it shows you a list of shards you hold for that person. If there are none, you hold none! Replaces the OthersShards / DarkCrystalFriendsIndex view as we no longer display this as an endless list. Makes the UI significantly less cluttered, a good thing IMO.

Views:

• ReplyNew - The Container view
• ShardList - Lists the Shards based on the scoped dataset
• ShardShow - A component / view of an individual shard (contained within the ShardIndex)

Components:

• Select
• DoubleCheck - Restates your selections and sends a message asking you to double check.
• AreYouSure
• CheckboxList
• Recipient
• Timestamp

3 - 'Recover a Crystal'

Nothing different from our current DarkCrystalShow view. Possibly could contain another stage to create a new request in RequestNew view which would be triggered with the request button.

Views:

• DarkCrystalShow / RitualShow (interchangable as its a one-to-one relation)
• RequestNew - optional extra view which shows clarification on who you are requesting from and the ritual details
• ShardList - (same as above)
• ShardShow - (same as above)

Components:

• AreYouSure
• Timestamp
• Recipient
• ProgressBar

4 - 'Forward Shards'

Adds a small amount of complexity but is intentionally in a separate arena from 'Return a Shard' so as to not confuse the actions (as stakes are high, right?). Allows a view of both shards that you hold that have not yet been forwarded using ShardList and shards that you have already forwarded using ForwardList, which are separated by tabs or a sidebar (or some other mechanism).

Views:

• ForwardIndex - The Container view which displays the ShardList and ForwardList views / components
• ForwardList - Lists all forwarded shards (using ShardShow)
• ShardList
• ShardShow
• ForwardNew - second stage of this section used to select the identity of the recipient of the forward message. Feeds the relevant information to the DoubleCheck component and finally the AreYouSure component before submitting.

Components:

• Select
• CheckboxList
• Timestamp
• DoubleCheck
• AreYouSure

#dark-crystal-diaries #dark-crystal #mmt

Some super generic components something along the lines of...

// components/select.js

function Select (collection) {
  h('select', 
    collection.map(option => {
      h('option', { value: option.id, name: option.name })
    })
  )
}

// components/are-you-sure.js

function AreYouSure (form, goBack) {
  h('div', { classList: ['are-you-sure'] }, [
    h('h2', 'Are you sure?'),
    h('button', { 'ev-click': (e) => goBack() }, 'No'),
    h('button', { 'ev-click': (e) => form.submit() }, 'Yes')
  ])
}

@kieran I love the pathways and agree that it's worthwhile to spend some time on the design this time round - we have time and knotches on our belt.

I also love the Pathways approach and feel this to be congruent with the trajectory towards the "Choose Your Own Adventure" Path. It is playful and yet serves the function to reduce mis-clicks.Great thinking.

I have pulled out each of the Pathways into their own threads so we can avoid a mess of a megathread.

These can be found:

• UI Pathways: 1 Home Page and 'Create a new Dark Crystal'
• UI Pathways: 2 - 'Return a Shard'
• UI Pathways: 3 - 'Recover a Crystal'
• UI Pathways: 4 - 'Forward Shards'

Perhaps we can use this thread that we are in now to speak about the Meta Level Thinking of Pathways etc and then leave specific comments about individual pathways in their specific threads :)

cc: @mix @kieran-two @peg

hey @kieran, have read over this, and just writing up a reply

To speak to your new designs

• (1B - new crystal) and (3 - recover a crystal) are in alignment with what we already have
• (1A - pick a pack home page) I'm not a fan, think there are clearer ways to lead people to the pathways. But also, that page is minimal to build, so go for it and we can A/ B test with it
• (2 - return some shards) we don't have the capacity to return just any shard at the moment. This could be a later iteration. The page you've designed is gonna be pretty similar to what I'm building at the moment, except you get to a persons shards but not via dropdown, rather by clicking on the persons avatar.
• (4 - forwarding shards) we didn't discuss forwarding only some shards, we discussed forwarding all shards, so that's what I think we should focus on first. It's also a lot easier to build. Individual shards might make more sense when shards have nicknames/ names. I like your confirmation screens, I think we should use those.

I'm not up for stopping the train to rehash the design process at this point. We're already underway, and what you're proposing would break momentum at a time when you're about to go away for a week and then it will be christmas.

With v1, things were incredibly turbulent with people travelling and handing over different bits of work. In that context, I decided to just build, because there was no space to get together and do a group design. I think if I hadn't, we may not have produced a prototype.

This time, I hosted a conversation where we all attempted to pin the minimum features down. Peg and I did a follow up call, and I then wrote up what I'd understood in Trello cards. That was up for a week at least, and then we started building. If you're looking for what I'm working on, look at Trello or my Dev Diary (there's info about the branch I'm working on there).

I know it can be hard when you're working on a different rhythm to others on the team. Let's talk about workflows and roles given our different constraints, and what needs improving, at our next weekly meeting. Does that sound good @dan hassan @peg ?

Kieran, I'm sorry if this comes across harshly. I am trying to look directly into the tensions I think we're feeling. I appreciate the work you did making your designs really clear and easy to discuss.

My recommendation for something for you to build now for the UI would be: the confirmations parts of (4 - shard forwarding). Imagine there's a button called [Forward All Shards] which when you click on it, starts you down the confirmation path. If you could jump on that, it would really support the momentum we've got going now, and I'd appreciate it

@kieran here's a pull request of my work : https://github.com/blockades/patchbay-dark-crystal/pull/18

It's ready for review if that's something you'd like to do

The point, as I highlighted in bold and have stated several times in my posts, is to keep the Forward and Return functionality as far away from each other as possible to help alleviate possibility of user mistake. I've said I feel strongly about this and its a mistake to overlook this... This isn't a piece of software that someone's going to be browsing. Its something you use with intention and direction. It has a specific set of purposes. You're going on a treasure hunt, its a story. It has a beginning, a middle, and an end. So the number of clicks and how pretty it appears at the early stage seems irrelevant and a distraction from whats important: designing to help people use it correctly (so they don't mess up and return a set of shards to the coconut robber).

See: %RbGrEHX...

Again, my point has been missed.

I'm not trying to derail your work @mix but I proposed a set of design approaches that were based around the point made in above post several times and each time the thrust of my point was overlooked. I made this point in my first post several weeks ago and have made it in each post subsequently. I don't think your design at the moment takes this into account, and if it does or you intend it to, then talk to me about it, because that is where my interests lie.

See backlinks where I made this point:

Falling Coconuts

The Dark Crystal interface really needs to separate user-flows and its narrative based on the differing scenarios / recovery strategies. For example, suppose rather than the simple case where peg's laptop gets smashed up by a falling cococnut, instead a giant walking cococnut robbed peg of his laptop (sorry peg!) and his identity with it. Supposing also that Peg has backed up both his Bitcoin private key and his SSB private key using that identity. When he comes to want to recover, the options to 'Return a Shard' and 'Forward a Shard' should not be in the same view. They could be easily mixed up and could result in a dramatic failure - rather than forwarding the old private key to the new SSB identity, peg's custodian sends the shard of the bitcoin private key back to the Coconut Robber. If a quorum of other shard holders makes the same mistake, then the bitcoin private key is revealed to the Robber.

The Dark Crystal interface doesn't at the moment allow a person to return a shard unless requested. But if the coconut robber has requested the bitcoin key shard back, it could easily be confused for forwarding the SSB key shard to a different identity. The interface really has to get a proper handle on this.

Interface for 'forwarding shards' / ssb identity recovery for dark crystal

So I feel like taking this kind of approach is important because it separates return shard completely from forward shard and makes it quite easy to understand what course of action is the right course of action. Also by streching it out into multiple views, it gives more space for warnings and information. Having it all compacted into a single view feels a bit dicey and doesn't leave much room for info notes or other helpful messages on how to use the app correctly.

UI Pathways

So I feel like taking this kind of approach is important because it separates return shard completely from forward shard and makes it quite easy to understand what course of action is the right course of action. Also by streching it out into multiple views, it gives more space for warnings and information. Having it all compacted into a single view feels a bit dicey and doesn't leave much room for info notes or other helpful messages on how to use the app correctly.

All I want acknowledged is we take this into account! I'm not really that fussed about my specific designs, but I do want that fundamental point to be accounted for, and at the moment it hasnt!

I even mentioned it in our design meeting before we went away when I asked the team to take into account my previous posts about the UI into consideration before moving forward!

Thanks @peg for the stake in the sand.

What I really dont want is us to end up 'competing' with different ideas for what it should look like, thats not interesting to me (or any of us I imagine) and is reproducing bullshit capitalist work paradigms. I want us to agree a set of common ideas and move forward. That means those that do want to have some input on what it should be like agreeing synchronously about it so we can move forward swiftly and with vision. That might not happen in a single meeting. In that case, it might mean making time for a couple of convergences. I'm more than happy to make the time for that.

@kieran you think that your design is the best way we have come up with to acheive the safest way to distinguish between returnShard and forwardShard. From the designs that I have seen, as I have said, I personally agree with you.

You might have missed this. This is what @mix has said:

(1A - pick a pack home page) I'm not a fan, think there are clearer ways to lead people to the pathways. But also, that page is minimal to build, so go for it and we can A/ B test with it

Mix has a different opinion on how to acheive the clearest way. I am assuming mix is also designing for safety.

The fact is - none of us are UX designers and we don't know. We have opinions which will need to be tested with Peers. We have a potential opportunity from the 7-11 of Jan at underExposed to work with acutal humans who are experts in this area. It would be excellent if we have a couple of branch variations BEFORE WE DO A VERSION RELEASE so that we can actually get some feedback beyond opinions.

The fact is that given our working rhytms and differentials on who is on the shop floor and when synchronous design meetings are REALLY FUCKING EXPENSIVE - as in there was a single window of 60 mins in our entire week which we managed to find cross over for our sync weekly meeting call - and the only way we could make that work is by me having to feed my kid, given them a bath and get them ready for bed at the same time as the meeting. Parenting level super human effort. I got a badge. Woo.

But the point I am trying to make is - right now, without our funding level and with our various rhtyms - we're doing the best we can.

Human Collaboration and Feelings Layer

Kieran is feeling not listened to and frustrated. In part this is because mix is jumping in and coding and rolling stuff out. Kieran you might consider doing the same.

Mix is feeling frustrated and worried that we're not going to hit targets. It might be good to clear state what targets you're aiming to hit, when and why.

Peg and Kieran have expressed concern about rushing and releasing extra versions which are not well thought through which, given we are designing security software, is dangerous as reputation is everything and each new version release adds complextiy overhead of support. This is really important we should discuss what we are trying to acheive by jan - I don't think it needs to be publicly released but can be a branch we can point EF at. That would be enough for me to work with EF on and advocate for more funding.

I am feeling resigned in the fact I can see where each person is coming from AND there are some emaotional blocks which are causing friction - I think we need to find a way of clearing this emotional block to acheive a more harmonions feelings layer.

If we were all in the same office this would not be happening. We're juggling different timezones, 3 of us have children < 2 so juggling babylyfe, we're juggling up coming holidays and travel.

As I have tried to express elsewhere I think the actual thiing we are trying to acheive right now is now a new release but delivering software ahead of schedule so that we can use this as a pointer for our discussions with EF. They have expressed this was meant to be a honeymoon period and that they are open to discussing in Jan the 2nd payment AND further funding.

I am personally feeling the weight of being the Man in the the Middle. As in I know you all more than you know eachother. I would love if you three could POW WOW this and commune before the weekly meeting. I am about to hop on a flight to EU so am going to be our of action over thaat period.

As I have said - I actually think the issues that we have are some differing opinions of strategy of working under the constraints that we are. That's about it.

There is tension happening around rhythm - that is I am on 2 days, @mix and @peg are on 3 days. We all seem to be spreading that work over the work week. That makes sense given the three of us are on babyLyfe schedules. @kieran is on two days a week but available for comms 4 days. Kieran you have expressed to me that you feel out of the loop and frustrated that the work that you do is out of Sync / not properly engaged with. I would agree that that is the case on both counts. Part of this was predicted right at the beginning when we had the re-gathering and I think myself, maybe peg, I know alanna and mix expressed that from experience the person arriving in to work at the end of the work week might find it smoothest if they allowed others to line up work for them. I recal that you expressed that you didn't need others to do that for you and it'd be cool.

I think part of what we're experiencing right now stems in part from that differential.

What we are learning to do is how software can be built in a non-Silicon-Valley way. Each go round the roundabout that we go we learning new things and experiencing new problems. This is all important stuff and it is ALL HARD. You know something is hard when @bob pops into your thread and says this is important AND hard.

This difficulty is not specific to us. Lets not take it personally. Lets do a reflection round, clear the emotional and psychic pipes, lets learn, lets share our learnings, lets build stuff and lets hop back on the merry go round to experience MORE difficult and challenges :)

cc: @kieran-two

@kieran I took your designs into account. What I didn't get from reading and looking at those was which part was non-negotiable for you. I think it's clear now, and it seems to be captured in a single sentence:

Forwarding and Returning need to be totally visually and physically isolated (to avoid any accidents / confusion)

Is that the crux of what you didn't feel heard on? If so then know that I agree with this principle.

What I'm surprised about is how big a deal there seems to be here if it's just this one sentence. Is there more than this one sentence that's a block? Some of the words I've heard you using suggest there might be. Here's some words that have snagged for me recently:

• unilateral decisions (re: that design session shape)
• competing
• bullshit capitalist paradigms

If we've got beef going on here we should escelate it to talking directly about what's going on. My guess is the form of our constraints is exacerbating a bunch of miscommuncation. This is laregly what I feared would happen. I spent and hour (1/4 of my work time for the day) yesterday trying to fold in your thinking and communicate clearly and hoping this wouldn't be a massive energy drain. I feel a really unpleasant tension where I know it's important to get to the heart of this, AND I feel upset about the idea of spending 2-3 hours talking about feelings when I am poor on time and energy, and I don't feel like it's going to change our situation much. (I could be very wrong about my assessment, that's just how I feel at the moment).

Yeah, I'm upset by this, I feel really annoyed.

My analysis is that at the core of this is that there's a power imbalance that we haven't clearly acknowledged, nor planned for and we're trying to pretend does not exist. Namely that mix and others have the luxury of being able to work on and in this a lot and Kieran doesn't. I think for Kieran he has a day job, and this is his idealistic work, and he wants it to conform to idealistic ways of working, specifically we're all equal and have equal steering rights. This is just my best guess. I think in practice it's hard for us to work with equal steering rights because we're on different tempos. I think the emerging informal dynamic is that I (and others) are making decisions and folding in Kieran's thinking, but that he's not an equal decision maker, he's more giving input and advice. To make decisions he'd have to be here more, but he's not. I'd love him to be here more, then we could talk about ideas and integrate them as we went, but we can't. I think I might be being perceived as a making decisions over or without Kieran. I feel like this is best available path (to make decisions and fold in input and advice). The alternative is that we reduce our tempo to match Kieran's. My assumption is we can't do that.

FWIW I think if Kieran and my roles were reversed we'd experience the same tension. I care about the things I work on, and I hate feeling left out.

This is just what I see or am modelling. I would be happy to be wrong. I look forward to hearing from others and updating how I'm thinking to better match what's going on.
I'd love to hear what others experience is.

@dan hassan you don't need to pick up the weight. Pointing at it and describing it's nature and inviting others to inquire is helpful (and easier on your back!)

quick note - I can see that @kieran already went ahead and did some design work today. I saw that afterwards in #manyverse which is more quickly consistent than my patchbay atm.

FWIW I think that actually the cheapest coordination way has been shown that quick prototypes might be a quicker way that super long design threads where we are all async trying to communicate... I'd suggest that we trial that in a purposeful way as one approach which might lead to more cohesion of thinking and feeling.

I am also aware @peg has said that he really doesn't want people to "waste" time on stuff which isn't used. I'd also say this extends to extended async conversations and massive threads... sometimes the most effective way is to write some code or interfaces - they may not go in as used, but they kick the can further down the forrest path :)

Love you all!

At the of what I think I am trying to say is that the conditions and constraints that we are working to nessecarily require a different way of working than if we were all in the same tz and location.

FWIW as I have said, I don't think we're super far way from this - it's something in expectations, hopes, communications pauses and practices which allow common understanding often... I think this is why in our particular case, for interface work actual prototypes built and referancable are likely the most effective way to that.

for things like underlying crypto - @peg's drum beat with keks and dominic with some input from mix has been shown to be a good longform method for that PLUS some deeper calls with mix to regather.

Compared to many projects and organisations I have worked in, working in the open and the level of communication and care we aim for means we are already really far along the Path to common space - we shouldn't forget this!

I get that I'm not around as much and I've been quite happy to let many decisions be made without me this run. The reason I'm frustrated is this is one that I really made a point several times of having an interest in and wanting my view to be taken into account, and I felt overlooked when it came to making that decision.

The distribution of time spent is an issue here. Spreading out 3 days a week over 7 (likely more than 3 in reality), rather than 2 days over (definitely more than 2 in reality), means yes I'm around less, but the input I have isn't that significantly less. This is something we should be wary of if we end up getting more funding and grow the team and have more different modes of working, we'll have to find common space and watch out for power imbalances. So going through this conversation is a positive. I don't agree that time spent and power should be in a linear relation. That's one of the drains I've seen in activist groups that causes them to be hierarchical despite wanting to be horizontal. Practically, I see how it emerges. Thats why process is important.

I'm not touching the idealistic thing. The default / walkaway analogy I used in the past was a bit of fun. They're different modes of working. Neither is perfect. But one is for sure more engaging and affirming than the other. You can guess which.

The irony here is for parents in default work, the opposite is usually the case, i.e. they get overlooked due to 'not being around enough' or 'being at home looking after the kids' and are systematically disempowered.

Dan said to me yesterday, and I might be being a bit reductive here, that conflict isn't a bad thing. While I don't entirely agree (i.e. we could all do without it), when it does happen, its a good opportunity for understanding, growth and change. So in that sense, when its well managed, it is good.

@mix re: personal stuff, lets talk in private, and don't feel like you have to prioritise it over getting work-related stuff done. I'll do the same. I've expressed I felt unheard. Now I feel like my point has been received and we can move forward from there. But I will say again, I do think we should have a sync chat soon.

thanks dan. I agree with a lot of that.

Can you please leave some space for response from Kieran

thanks @kieran, yeah would be good to re-align.

I think we need to be wary of power, which is why I named it. I think your point about parents being generally systemically disempowered was really pertinent. I'm definitely coming from a place where I don't think flatness is the panacea - rather I think it's a useful challenge to un-conscious or abusive hierarchy. What I want to be more clear of is where is there power, and where is that good and consented, and where is it not.

The concrete case would be "do Mix / Peg / Dan have mandate to make plans without Kieran. If so, what sort of plans"

For those reading along Kieran and I are setting up a call to sync up