Design - Wireframes

[Baltsar]

Here is my process so far @Lemonado114 @amiuhle . I am not sure if I can call it "wireframe" since I already styled it a bit

I only had time to do one view and that is BUYER on a IPAD and I made it so simple as possible for the buyer.

IPAD DESIGN
Changes

• I ditched the two columns idea since I want to make it so simple as possible
• The bill is minimized in a button that pop ups as overlay
• Big fat buttons, so you can use your fingers properly ;)
• I designed just centre everything and used no grid or template, let me know what kind of frame work we are building this in.
  

---

---

---

Discussion

• Do we need a seller view?, can it be hidden, do the buyer need to know the view..here is something we can discuss if the split view is optimal for this kind of transactions.
• Anything you see missing or have opinion let me know

Keep in touch!

[amiuhle]

For context to everyone else, here's what I had previously written in an email about the split view:

However, there are some technical issues with this (barcode changes because amount changes, but I don't know when the barcode was scanned, so I might be listening for a lower amount than what's currently displayed and it won't get accepted). So I think having a wizard-kind of workflow will be better. Also, it'll be easier to make it work on different screen sizes (Android phone for waitress in a restaurant, for example).

Now, my feedback on the wireframes:

Do we need a seller view?, can it be hidden, do the buyer need to know the view..here is something we can discuss if the split view is optimal for this kind of transactions.

I think we have to forget about the split view for now. When looking at the screens above, I see another problem: The keyboard will always show up on the same side, there's no way to influence this. When the buyer clicks on the input field for the tip, the keyboard will appear on the seller's side.

Why don't we try this workflow:

1. Seller View is displayed
2. Seller enters details on the seller view
   Amount, in USD
   (optional) Recipient ID, or an image of the receipt / bill
3. Seller clicks on Request Payment
4. Buyer View shows up
5. (optional) Buyer enters amount for tip
6. Buyer clicks on Send Payment (or Next, Continue, etc)
7. Payment View shows up
   Barcode, Address
   Once the payment is received, show Confirmation and transaction id

I wanted to use nested lists for this, but GitHub Markdown wouldn't let me. I hope it's still understandable.

The buyer doesn't need to see the picture taken of the bill, they will get this printed version. The seller will have a copy or a digital record of it. The receipt id (or image of the receipt) is just a requirement for the seller to later link the Monero transaction id to the receipt the payment was made for.

The buyer will optionally get another printed receipt with the Monero transaction id (there could also be another barcode for this).

Both those are what I think are requirements to meet legal requirements for taxation. Any feedback on whether I'm right on this is welcome in #6

Some more random thoughts when looking over the wireframes:

• Tip is the correct term, not Extra
• This will probably be translated, so some labels might be longer than the English ones
• Show some options for tip amounts. In the example above, this might be 0.1. Display two or three of them, I will figure out a way to make an educated guess.
• The barcode image will have to be larger because there is more information encoded, see testnet sample below

I designed just centre everything and used no grid or template, let me know what kind of frame work we are building this in.

I will use whatever is best to implement the design you made (probably no framework at all, just plain CSS targeting modern browsers). Use whatever grid or template you want, just focus on good design and user experience, please!

I'll try to make things as app-like as possible in a decent mobile browser, so there will be transitions and stuff. Maybe it's best if you forget about the browser when designing.
Just think of it as a native app on Android or iOS, and I'll do my best to make it feel like one.

---

Barcode sample:

[Lemonado114]

Thats a good idea, I didn't think i seller view would be good either

[Baltsar]

Thanks for the feedback,

The notification were disabled by default. I haven't forget about this and doing some sketching during my spare time. Hold out!

[Baltsar]

# 🖊 2.0 KASISTO SELLERS VIEW FLOW- WIREFRAME

@Lemonado114 @amiuhle

I just throw it out there and feedback is much welcome.

## PROTOTYPE : https://invis.io/S9C2LQ4BU (4 days left on my trial)

## OVERVIEW : http://imgur.com/a/9O5h7

• Not every function works
• I do not know how the confirmation/sending XMR works technical and how it will be confirmed
• Screen 7 The transaction list needs more work
• I assume payment ID is integrated into the adress

QUESTIONS
Do we need an account creation to use Kasisto?

""Shit loads of edit in this post""

[amiuhle]

Perfect timing!

I got some refactoring of the code done in the last couple of days and was missing some inspiration on how to arrange the views.

The concept looks good, I'll reply in detail when I'm done with the refactoring and have some more insights.

What comes to my mind right right now:

• Confirmation of payment will work in the background. Kasisto will scan the blockchain for incoming payments, so in practice, the customer will scan the barcode, confirm payment on their phone, and a couple of seconds later the payment will be confirmed.
• Yes, the payment id is in an integrated address
• I think the categories / tags aren't needed. I imagine that in practice, the customer will most likely be able to see what the seller is doing on their phone. Also, it has to be fast. I don't think anyone will bother with entering stuff that's unnecessary for the payment process.
• Tips should round up to an even number. In the example above (0.018 XMR) I think Kasisto should suggest 0.019, 0.02 and 0.021, for example.

[amiuhle]

Some more feedback:

• There needs to be a restricted section for sellers. This includes configuration, but also the list of bills / payments, for example. This section will be password protected, because the buyer has direct access to the device (to enter amount for tip).
• Currency selection can go into the settings, as well. The seller will be in a certain country, so there's no need to regularly change the currency.
• A related setting will be the exchange to get exchange rates from. I think I will start out with Kraken and USD/EUR as currencies. More currencies and exchanges can be added later, maybe by some community pull requests.
• The current exchange rate could be displayed in a status bar. Or as some kind of "screensaver" before the seller taps it to make a new payment.

So currently I think there should be a hamburger menu or some other access like swiping to show a menu, which is password protected. It currently contains recent payments and settings as menu items.

Then there's the seller view and the buyer view, and it's just about the payment process.

That's my target for a first alpha release. Then we'll see what the community wants from there.

Cc @Baltsar