Closed dmfs closed 7 years ago
A few questions for this story:
@dmfs, @wilfred We currently have the Book action with 4 subtypes: ticket, hotel, taxi, parking Do we use the Button for only ‘ticket’ and make Action items for the others? Or we define a precedence among them and the most important one will be the Button, the rest are Action items if there is more than one? We can also defer this question for later if it’s confirmed that we don’t support those other 3 at the moment.
I don’t have the final design yet, so could you please confirm these about the Button: It is a custom styled button, not simply standard Android one with color changed to green. (You can check the standard button on the demo app home screen, try pressing, holding down and swiping off from the button to see the colors, ripple, shadow animations). More specifically it has no shadow, has rounder corners, and doesn’t use capital case letters. It should also still have animation when pressed: darker green and ripple effect.
@dmfs The scrolling behaviour you posted the video about - is that how it should work, and if it is, do you have the code for that somewhere? Or should I just start to do it on my own? (You mentioned some issues with the anchoring.)
@lemonboston you'll get access to the invision mockups to get the final design. For now ignore any other action than "book". The book button should only respond to the book action. If there is no book action the button should not be visible, obviously.
The button will use standard Material design.
I didn't really write any code to "implement" that scrolling behavior. I just anchored the button FrameLayout to the footer placeholder. However, that only worked if the content was larger than the screen. I think it should work by anchoring it to the actual footer, but that didn't work for me. So we probably have to write a custom behavior that works similar to the footer behavior. It shouldn't take more than half a day.
@lemonboston I think you have the wrong user?
Fortunately, the scrolling behavior could be solved simply by anchoring the button to top of the footer. It works with both short and long content.
About the book action, so there are the 4 subtypes for it all having different labels and icons defined previously in BookAction
class. Do we ignore for now the book/hotel, book/taxi, book/parking links and only filter for book/ticket and show that as button if present?
Or should we keep the other 3 displayed as Actions?
Here is a Link I debugged:
{
"href": "https://actions.schedjoules.com/actions/26b989a03726e4e9",
"properties": {
"http://schedjoules.com/props/booking/currency": "EUR",
"http://schedjoules.com/props/booking/price-max": 14.18,
"http://schedjoules.com/props/booking/price-min": 14.18,
"http://schedjoules.com/props/booking/sale-end": "2017-03-22T06:00:00Z",
"http://schedjoules.com/props/booking/sale-start": "2016-12-09T10:00:00Z",
"http://schedjoules.com/props/booking/sale-status": "onsale",
"http://schedjoules.com/props/booking/type": "ticket",
"http://schedjoules.com/props/vendor/icon": "data:image/png;base64,XXXXXXXXX"
},
"rel": "http://schedjoules.com/rel/action/book"
}
So do we only show the button for ../type": "ticket"
or for any kind of ..action/book
?
Should we implement adding the price to the button label in this story or as a separate one? The question is the format there: <prince-min> <currency-name>
? Or <currency-symbol><price-min>
when we have a mapping for that currency?
(edit: the formats the other way around)
@wilfred oh, yes, I am sorry for disturbing!
@wilfredstegeman so I intended to mention you there up a few comments
In my previous post I mean to ignore the other "sub-actions". The book button only shows book actions with the sub-type "ticket". The price will be handled in a separate story to keep the scope of this story small. Same goes for handling of tickets that are not on sale yet.
Ok, thanks, setting this to 'blocked' until design is available.
@dmfs , @wilfredstegeman Can you please provide the German and Dutch translations for the "GET YOUR TICKETS" button label?
English: Get Tickets Dutch: Tickets Kopen German: Tickets Bestellen
Thanks
I suggest to use "Karten bestellen" for the German version.
I took the translations from Eventbrite. I checked some other large German event portals like Eventim and Reservix and they all name it "Tickets" or "Tickets Bestellen". @dmfs what makes "Karten bestellen" the better option would you say?
Yes, I know that "Tickets" is quite common in this kind of app. However, I believe that's not what most people would say. If you're planning to go to a concert or to a cinema, most people would buy "Karten" rather than "Tickets". Even for tram and train it's less common. I think flights are one of the few areas in which the term "ticket" is common.
I don't disagree with you, but with 'Karten' we'll be the odd ones out, because hardly anybody else uses Karten. In apps and on websites people are therefore used to it, despite of what they may say in real life. I do think that especially at this moment of our development it's best that for these kind of elements that are common, we choose beaten tracks. I've checked a few more like Viagogo, Tickets.de and Tickets.rtl.de and they all only mention Tickets on their CTAs. They do use Karten sometimes, but only for SEO reasons in non-vital areas of their site. We can always A/B test this once we're more settled, so I suggest, also to be consistent, to go for Tickets for now.
It's not necessarily a bad thing if we stand out with "Karten". But I'm fine if we go with "Tickets" for now.
@dmfs commented on Mon Mar 06 2017
In order to have a clear call to action, as a user I want a sticky "Get tickets" button.
The button gets a transparent Background an a (yet to be defined) green tint It also gets a custom scrolling behavior as seen here: https://schedjoules.slack.com/files/marten/F4E46PNUA/device-2017-03-06-130705.mp4
Also, filter the book action from the action bar.