darkhelm/notifications-admin
1
0
Fork 0
mirror of https://github.com/GSA/notifications-admin.git synced 2026-09-02 17:48:50 -04:00
Code Issues Packages Projects Releases Wiki Activity
Files
1a8d4fda696c0f346c9f95af3be9659e4616efd2
notifications-admin/app/assets/stylesheets/components/email-message.scss

49 lines
703 B
SCSS
Raw Normal View History

Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
.email-message {
margin-bottom: $gutter;
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app
2016-02-18 14:54:59 +00:00
&-name {
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
@include bold-19;
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app
2016-02-18 14:54:59 +00:00
margin: 20px 0 10px 0;
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
}
Make email pattern work in new context The email pattern looked a bit shonky when displayed in a narrower column. This commit fixes it by making the email’s metadata (eg subject, from) into a table, which it sort of is. This means that it is more flexible about the size of container in which it sits.
2016-02-23 14:58:49 +00:00
&-meta {
@include core-19;
margin: 0;
td,
th {
@include core-19;
border-bottom: 0;
border-top: 1px solid $border-colour;
Fix bug which prevented viewing an email job The template for viewing a job was not getting all the variables it needed in order to display an email template. Hadn’t noticed this before, because email templates require more variables than SMS templates. This commit fixes that bug.
2016-03-09 12:18:11 +00:00
vertical-align: top;
Make email pattern work in new context The email pattern looked a bit shonky when displayed in a narrower column. This commit fixes it by making the email’s metadata (eg subject, from) into a table, which it sort of is. This means that it is more flexible about the size of container in which it sits.
2016-02-23 14:58:49 +00:00
}
th {
color: $secondary-text-colour;
}
td {
width: 99%;
}
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
}
Preview service name when adding a new service This commit adds a new page, which appears after a user enters the name for their new service. It shows how the service name will appear in emails and text messages. This means that the new service is not created until after they have confirmed that the name is appropriate in context. This has also involved: - visual changes to the ‘email template’ pattern, which wasn’t very refined before - removing a bunch of words from the enter service name page, because most users don’t read them, and we reckon that showing a preview is a better way of getting them to understand what is meant by service name Still to do: - validating the the generated email address for a service is unique (on the API) side - having the API return the generated email address, rather than determining it in the admin app
2016-02-18 14:54:59 +00:00
&-from {
padding-top: 15px;
border-top: 1px solid $border-colour;
}
&-body {
width: 100%;
box-sizing: border-box;
padding: $gutter-half 0 0 0;
margin: 0 0 $gutter 0;
clear: both;
border-top: 1px solid $border-colour;
border-bottom: 1px solid $border-colour;
Add a prototype email template If the templates page contains text messages and emails then there’s two ways it could be structured: - into two sections, all text messages first, then all emails - emails and text messages interleaved, sorted by date I think the second one is better. Imagine a situation where you mostly do emails but have a few text messages. You’d have to scroll past the text messages to get to your emails. Every time. I reckon that the most commonly accessed templates will be the most recent ones.
2016-01-13 16:27:54 +00:00
}
}
Reference in New Issue Copy Permalink