Means you can see, for example emails that have failed.
Means adding:
- logic to generate links which can have a type parameter, a status
parameter, or both
- a ‘pill’ UI component for seeing which filters you currently have
applied
- some logic to change the page title based on which filters you have
applied
This table had a lot of columns, which meant that some of them became
very narrow, wrapping the text awkwardly.
This commit groups some of the data into a chunk, which occupies the
first column.
> At the moment, we have an all email templates page, and an edit an
> individual page.
>
> This gets messy when we refer to templates like the dashboard and the
> activity views. We solve this currently by using anchor links to the
> list page, but this is clunky.
>
> So lets add it, then update the links on the dash and activity to the
> new view page.
>
> Should be a link from the view a single template page, to the template
> hub page.
https://www.pivotaltracker.com/story/show/117349227
It’s a bit silly to have email templates expandable if you’re only going
to reveal a couple more lines.
This commit adds a data attribute which specifies how high (in pixels)
the email template can be before it gets truncated. It then changes the
script to only truncate emails which are naturally taller than this
height.
Currently the cut off is at 200px, which is approximately 8 lines of
text: `200px / (font-size: 19px * line-height: 1.31) = 8.03`
Emails can get very long.
When you’re trying to do other things on the page this results in a lot
of scrolling.
This commit truncates email messages to about 3 lines, and adds a JS
toggle which reveal the full contents of the email.
If a user puts a linebreak in an SMS template then the recipient will
see these linebreaks on their phone. So when we show a preview of an SMS
template, it should have linebreaks in it.
On:
- the API keys page
- the ‘send’ page
There are some inconsistently small heading sizes. This commit makes them
consistent with the heading sizes on other pages.
We have lots of keylines in our pages, eg tables, email message previews
This makes the pages look quite cluttered, especially because the
keylines don’t always align.
I think it looks much cleaner without the keylines in the nav, and we
have few enough nav items that we don’t need to chunk them up.
On the send page, it should hightlight the placeholders so they match
what you need to put in the CSV file.
On the check page, they should not be highlighted, to match what’s in
the (rendered) template.
We’ve seen in research that people can be reticent to give their real
phone number. Telling them that it will be used for something should
help (ie we’re not just collecting it for marketing).
This also rewords the other form hints on this page to be less computery
because we haven’t looked at them in aaaages.
This caused some anxiety about why the rows were being hidden. Were
there problems with them?
This commit reframes the wording to talk about the rows that are shown
instead.
> Trial mode page – if signed in, make your team into a link to the Team
> members page for the last-used service.
> Trial mode – if signed in, make remove these restrictions into a link to
> the Request to go live page for the last-used service.
(except view activity, natch)
> No permissions – Remove trial mode banner
> No permissions – Add blue banner saying 'You only have permission to
view this service'
For email jobs, the template needed to look up the service to work out
the email_from and from_name.
`service` used to be a variable passed through to the view. Now every
veiw gets `current_service` instead.
This is a quick fix to make things work.
When a table is showing the contents of a CSV file, it should look
something like a spreadsheet.
The minimally skeuomorphic way to do this is by adding row numbers.
This commit doesn’t
- make the row numbers monospace (it’s barely noticeable and doesn’t
reflect what actual spreadsheets do)
- make the first column heading ‘Row’ (again, doesn’t reflect how actual
spreadsheets work, and takes up more valuable space)
SVG images will look sharper and scale more cleanly. However they are
not supported on older browsers[1]
> The <picture> element allows for fallback images when the browser
> doesn't support a specified image format.
`<picture>` is supported in the latest versions of Chrome, Firefox, IE
(Edge), Safari and Android, so all these browsers will get the SVG
version.
Older browsers will fall back to the PNG version.
[1] http://caniuse.com/#feat=svg
[2] https://css-tricks.com/a-complete-guide-to-svg-fallbacks/#fallback-svg-as-img-picture
[3] http://caniuse.com/#feat=SVG
