schedjoules / android-event-discovery-sdk

0 stars 1 forks source link

Implement ticket button #136

Closed dmfs closed 7 years ago

dmfs commented 7 years ago

@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 bildschirmfoto vom 2017-03-06 21-03-54 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.

lemonboston commented 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.)

dmfs commented 7 years ago

@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.

Wilfred commented 7 years ago

@lemonboston I think you have the wrong user?

lemonboston commented 7 years ago

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)

lemonboston commented 7 years ago

@wilfred oh, yes, I am sorry for disturbing!

@wilfredstegeman so I intended to mention you there up a few comments

dmfs commented 7 years ago

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.

lemonboston commented 7 years ago

Ok, thanks, setting this to 'blocked' until design is available.

lemonboston commented 7 years ago

@dmfs , @wilfredstegeman Can you please provide the German and Dutch translations for the "GET YOUR TICKETS" button label?

wilfredstegeman commented 7 years ago

English: Get Tickets Dutch: Tickets Kopen German: Tickets Bestellen

lemonboston commented 7 years ago

Thanks

dmfs commented 7 years ago

I suggest to use "Karten bestellen" for the German version.

wilfredstegeman commented 7 years ago

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?

eventbrite

eventim

reservix

ticketonline

dmfs commented 7 years ago

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.

wilfredstegeman commented 7 years ago

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.

dmfs commented 7 years ago

It's not necessarily a bad thing if we stand out with "Karten". But I'm fine if we go with "Tickets" for now.