Some Example Emails That Need Styling

3081 views
Skip to first unread message

Casey Watts

unread,
Jan 30, 2013, 12:23:38 AM1/30/13
to markdo...@googlegroups.com
Hi CTs,


#Email
Please read through our emails carefully, as if you're getting paid to do so. Because you are!

Hint: there is a payform code in this email. Please include the code in the
Description of your email payform item, see [Payform](
billing email.

#Contacting Managers
It is always better to email all of us rather than just one of us. It's easier for us when we both know what's going on, and you're more likely to get a quicker response.

You can contact your managers Derek, Casey and Yahor at their joint email address `em...@yale.edu`. 

To see the full list of email addresses STC uses, check the weke article [STC Email Lists](http://weke.its.yale.edu/wiki/index.php/STC_Email_Lists)


#Shift Scheduling

Now that you know your class schedule, we can start to schedule the shifts for the rest of the semester. Please carefully read and follow our instructions on [Shift Scheduling Process](http://weke.its.yale.edu/wiki/index.php/Shift_Scheduling_Process#Spring_2013_-_Cluster_Tech_Shift_Requests)

Important dates:

- Deadline for submitting request: **Monday, January 28th by midnight**
- Permanent schedule goes into effect: **Thursday, January 31st at 9am**

#Shift/Cluster Demo

If you haven't filled out Yahor's survey yet, please do so ASAP:

Yahor is going to walk you through one of the zones and show you the kilroy process. 

This demo is mandatory for all New CTs.

#Weke Homework
Please read/look over the following articles for homework, and bill for it on your payform. They're all linked to from the front page of the [WekeWiki](http://weke.its.yale.edu/wiki/index.php/Main_Page)

- ITS Contact Info
- STC Email Lists
- Shifts
- Payform
- Wekewiki

FYI - not the entire weke is up to date. Some articles still say "ST" to mean "student employee". The ones we use often and that we've actively reviewed recently have a "stamp" at the top-right of the page which says "STC Approved (year)".


#Payforms

Don't forget to submit your payforms by Sunday 10pm! For this week's payform code, give us some feedback about Monday's CT training. Did you have a good understanding of the job after Monday? Was it too long/too short? 

When you receive an email from Student Employment about e-timesheets, you can disregard that message. STC uses Shifts Payforms instead.

#That's all
Have a great weekend and let us know if you have any questions!

-- 
Derek, Casey, and Yahor

Casey Watts

unread,
Jan 30, 2013, 12:25:08 AM1/30/13
to markdo...@googlegroups.com
Rendered with 



Hi CTs,

Email

Please read through our emails carefully, as if you're getting paid to do so. Because you are!

Hint: there is a payform code in this email. Please include the code in the Description of your email payform item, see Payform for details about billing email.

Contacting Managers

It is always better to email all of us rather than just one of us. It's easier for us when we both know what's going on, and you're more likely to get a quicker response.

You can contact your managers Derek, Casey and Yahor at their joint email address em...@yale.edu.

To see the full list of email addresses STC uses, check the weke article STC Email Lists

Shift Scheduling

Now that you know your class schedule, we can start to schedule the shifts for the rest of the semester. Please carefully read and follow our instructions on Shift Scheduling Process

Important dates:

  • Deadline for submitting request: Monday, January 28th by midnight
  • Permanent schedule goes into effect: Thursday, January 31st at 9am

Shift/Cluster Demo

If you haven't filled out Yahor's survey yet, please do so ASAP: http://whenisgood.net/theIDofapoll

Yahor is going to walk you through one of the zones and show you the kilroy process.

This demo is mandatory for all New CTs.

Weke Homework

Please read/look over the following articles for homework, and bill for it on your payform. They're all linked to from the front page of the WekeWiki

  • ITS Contact Info
  • STC Email Lists
  • Shifts
  • Payform
  • Wekewiki

FYI - not the entire weke is up to date. Some articles still say "ST" to mean "student employee". The ones we use often and that we've actively reviewed recently have a "stamp" at the top-right of the page which says "STC Approved (year)".

Payforms

Don't forget to submit your payforms by Sunday 10pm! For this week's payform code, give us some feedback about Monday's CT training. Did you have a good understanding of the job after Monday? Was it too long/too short?

When you receive an email from Student Employment about e-timesheets, you can disregard that message. STC uses Shifts Payforms instead.

That's all

Have a great weekend and let us know if you have any questions!

Casey Watts

unread,
Jan 30, 2013, 12:27:19 AM1/30/13
to markdo...@googlegroups.com
Hi STs,

#Email
Please read through our emails carefully and deliberately, as if you're
getting paid to do so. Because you are!

A few of you don't ever bill for email, and you should. Please read and add
email time to your payforms, it's part of your job :)

Hint: there is a payform code in this email. Please include this in the
Description of your email payform item, see [Payform](
billing email.

#Scheduling

## Open sign-ups 1/20-1/30

(**New STs**, please ignore this section)

Reminder: please sign up for at least 8 hours of shifts between 1/20-1/30.
If you were short from the last period, please try to make-up the hours
during this period

We just opened signups for Wednesday, January 30th.

## Spring 2013 Permanent Shift Schedule

(**New STs**, please ignore this section - you'll be scheduled in a future round)

It's the time of year again to set the permanent shift schedule! Please
carefully read and follow the instructions here: [Spring 2013 - ST Shift

Important dates:

- Deadline for submitting request: **Monday, January 28th by midnight**
- Permanent schedule goes into effect: **Thursday, January 31st at 9am**

#Lateness and Discipline
## Late Payforms
You should no longer use the SEO web form to submit late payforms. We can
do it for you, as long as it's submitted through Shifts. You can thank
Student Employment for being flexible! :D

## Three Strike System
We're going to be significantly less tolerant of missed shifts this
semester. Missing shifts is not okay, don't do it.

We're reinstating the [Three Strike System](

##Sub Requests
If you put in a sub request and it's taken by someone, **you're responsible
for taking someone else's sub request.** See the [Shifts](

#Contacting Managers
It is always better to email all of us rather than just one of us. It's easier for us when we both know what's going on, and you're more likely to get a quicker response.

You can contact the ST managers Derek and Casey at their joint email address `em...@yale.edu`. For this week's email code, include the best email address at which you can contact Derek and Casey.

To see the full list of email addresses STC uses, check the weke article [STC Email Lists](http://weke.its.yale.edu/wiki/index.php/STC_Email_Lists)

We prefer you don't use `em...@yale.edu` (=DerekCaseyLori) anymore. That one won't work when one of us eventually leaves.

#io/TTO
## io - Checking In Parts
When parts arrive in the io, please reference the [Parts](
the main page.

Only MacSpecs should check in Apple parts (all Apple parts are shipped from
"AI" = Apple Incorporated).

## Symantec
OS X: [Symantec now works on OS X 10.8!](
We officially recommend that all students have Symantec, even on OS X. Many
students won't want this and we don't have to force them.

Windows: We absolutely recommend that all Windows users have Symantec
installed. If you see anyone who doesn't have it, you should strongly
encourage them to have it.


## Bass Laptops & Cell Phones

- Bass now manages the YCC loaners that can be checked out by anyone, for up to two weeks. We should recommend this to students who aren't eligible for the ST Loaner Laptops
- Bass also has the loaner cell phones; we won't have to worry about those
any more.
- If a student with a Bass loaner has a hardware problem, they should
exchange it for a working one through Bass. Bass will contact us to fix the original, broken loaner. Do not take a Bass loaner from a student directly in the TTO.
- If a student has questions about using a Bass loaner they can come to the TTO and we'll support the laptop as if it's a personal laptop.

-- 
Derek and Casey

Casey Watts

unread,
Jan 30, 2013, 12:29:01 AM1/30/13
to markdo...@googlegroups.com

Email

Please read through our emails carefully and deliberately, as if you're getting paid to do so. Because you are!

A few of you don't ever bill for email, and you should. Please read and add email time to your payforms, it's part of your job :)

Hint: there is a payform code in this email. Please include this in the Description of your email payform item, see Payform for details about billing email.

Scheduling

Open sign-ups 1/20-1/30

(New STs, please ignore this section)

Reminder: please sign up for at least 8 hours of shifts between 1/20-1/30. If you were short from the last period, please try to make-up the hours during this period

We just opened signups for Wednesday, January 30th.

Spring 2013 Permanent Shift Schedule

(New STs, please ignore this section - you'll be scheduled in a future round)

It's the time of year again to set the permanent shift schedule! Please carefully read and follow the instructions here: Spring 2013 - ST Shift Requests

Important dates:

  • Deadline for submitting request: Monday, January 28th by midnight
  • Permanent schedule goes into effect: Thursday, January 31st at 9am

Lateness and Discipline

Late Payforms

You should no longer use the SEO web form to submit late payforms. We can do it for you, as long as it's submitted through Shifts. You can thank Student Employment for being flexible! :D

Three Strike System

We're going to be significantly less tolerant of missed shifts this semester. Missing shifts is not okay, don't do it.

We're reinstating the Three Strike System.

Sub Requests

If you put in a sub request and it's taken by someone, you're responsible for taking someone else's sub request. See the Shifts article for details.

Contacting Managers

It is always better to email all of us rather than just one of us. It's easier for us when we both know what's going on, and you're more likely to get a quicker response.

You can contact the ST managers Derek and Casey at their joint email address em...@yale.edu. For this week's email code, include the best email address at which you can contact Derek and Casey.

To see the full list of email addresses STC uses, check the weke article STC Email Lists

We prefer you don't use em...@yale.edu (=DerekCaseyLori) anymore. That one won't work when one of us eventually leaves.

io/TTO

io - Checking In Parts

When parts arrive in the io, please reference the Parts article, now linked to from the main page.

Only MacSpecs should check in Apple parts (all Apple parts are shipped from "AI" = Apple Incorporated).

Symantec

OS X: Symantec now works on OS X 10.8! We officially recommend that all students have Symantec, even on OS X. Many students won't want this and we don't have to force them.

Windows: We absolutely recommend that all Windows users have Symantec installed. If you see anyone who doesn't have it, you should strongly encourage them to have it.

Bass Laptops & Cell Phones

    • Bass now manages the YCC loaners that can be checked out by anyone, for up to two weeks. We should recommend this to students who aren't eligible for the ST Loaner Laptops
    • Bass also has the loaner cell phones; we won't have to worry about those any more.
    • If a student with a Bass loaner has a hardware problem, they should exchange it for a working one through Bass. Bass will contact us to fix the original, broken loaner. Do not take a Bass loaner from a student directly in the TTO.
    • If a student has questions about using a Bass loaner they can come to the TTO and we'll support the laptop as if it's a personal laptop.
      -- 
      Derek and Casey

      Casey Watts

      unread,
      Jan 30, 2013, 12:39:21 AM1/30/13
      to markdo...@googlegroups.com

      I hope these examples can be useful in making CSS decisions. The CSS I'm using shouldn't be the standard, but there are some useful things about it, most of which Adam's already put in the "default styling discussion" thread

      Things I don't like about this specific CSS:

      1. Bullets are way more indented than paragraphs, and I'm trying to use them as sorta the same. I guess I probably shouldn't use them that way. Bullets do look appropriate under "Spring 2013 Permanent Shift Schedule"
      2. I do like text indented relative to the headers (especially h2, with the underline). You can see that it's kinda pretty that way :) But it's not great to always indent every paragraph, I'm not sure that's the best way to do it. The very top of the email always looks slightly odd.
      3. Every email's salutation should be slightly apart from the body in my opinion, but I have no way to accomplish that in Markdown and no particular suggestion to improve it either. (It's not apparent here, because the h1's top margin saves the day.)

      Adam Pritchard

      unread,
      Jan 30, 2013, 10:31:19 PM1/30/13
      to markdo...@googlegroups.com

      Thanks for the interesting examples. They represent a rather different use case than mine: Your examples are newsletter mailings (ish) and I typically use it for day-to-day email containing code, lists, emphasis, and typically not very long. Do you also use Markdown Here for less formal missives?

      This makes me think of something that I've been ruminating on for a while: CSS themes (for the "primary styling CSS", separate from syntax highlighting themes). Users (like you, maybe) may have different email modalities when MDH is useful to them, but they might need different styling in those modes. In addition, if a user uses MDH in email and also Evernote and also Wordpress, then they may want things to look significantly different in those environments.

      On the other hand, there are a bunch of ifs and maybes in there, and I don't want to create a bunch of work for myself without a good reason. I probably wouldn't use this feature myself.

      Regarding your points:

      1. Bullets: After looking at your examples, I realized that there are (at least) two very different ways to use a bullet list. One is exemplified by your "Bass Laptops & Cell Phones" section: longer sentences, sometimes multiple sentences; almost full paragraphs. The other way is exemplified by your "Weke Homework" list (and "Spring 2013 Permanent Shift Schedule"): only a few words in each point, just a single datum. I suspect that these different uses would benefit from different styling: more paragraph-like for the former, with less space on the left and more between the points, whereas the latter is maybe better with more space on the left but less vertical spacing.

        I think I tend to use the almost-paragraph bullets more than the other, so that's probably why my styling trends that way. I don't have any magical ideas (or CSS selectors) for doing them differently.

      2. Text indent: Yes, it certainly does look good in your email. Since mine typically have a less formal structure, I prefer a more standard indent (or lack thereof).

        I can maybe suggest how to have different indents for paragraphs under a h1 than under a h2, although it looks kinda dirty. It uses sibling selectors.

        /* Match the first para after a H1, the second para after a H1, etc. */
        h1+p, h1+p+p, h1+p+p+p /* etc. */ {
         color: red;
         /* or something more useful like change the margin */
        }

        You'll have to keep creating rules with +p for whatever the maximum number of paragraphs under a h1 you might have. Kinda horrible, but I can't think of anything better.

      3. I don't disagree, but I'm really loathe to introduce something that attempts to detect a salutation and style/render it differently. However, I can maybe suggest a CSS trick to selectively style yours, though:

        /* Style the first para that's an immediate child of the wrapper (e.g., the salutation) */
        div.markdown-here-wrapper > p:first-of-type {
         color: red;
        }

        Note that this won't work so well if you do selection-based Markdown Toggling, rather than doing the whole thing at once; the first paragraph of each separately rendered selection will be red. (More pseudo-selectors here. I can't pretend I didn't have to look them up.)

      (Note to self: Make a note about supporting LESS/SASS and maybe JS post-processing of rendered output. Sometime in the far-flung future.)

      Casey Watts

      unread,
      Jan 30, 2013, 10:50:56 PM1/30/13
      to markdo...@googlegroups.com
      Here's a less formal email I've done:



      Hi Roger and Dorothy!

      Thanks for the training today :)

      (Friend and Friend, just sending this to you in case you're interested. You'll go to this training in January)

      Here are notes from me:

      - Notes are really just for me.
      - Suggestions might help with the next iteration of the presentations - I'm trying to be helpful, let me know if I can clarify anything :)
      - Questions we might want to answer for the whole class, maybe via a group email?

      #First Last - ITS Website
      ##Notes:

      Web team

      - First Last
      - First Last
      - Bob (what's his last name?)

      Supervisors

      - First
      - ?

      Auto-file a ticket in SN = em...@yale.edu

      - Copy-editor - syntax, punctuation, etc
      - Line-editor - content, structure

      ##Questions
      - Since we should only edit our own pages - who are the SMEs and how do we find them?

      ##Suggestions
      - Start with an example of an edit anyone might make, and take us through using that? Ex: How-to article (does this exist?)
      - A lot of worry came through in the presentation, maybe more than necessary. Worry about getting bad edits.
      - One too many "goal" slides?
      - "Reduce burden on help desk" => help clients find information on their own if they want (and a lot want)
      - How to - Licensing Our Own Photos

      ##Comments
      - SEP example - great!


      #Dorothy - Service Now Knowledge Base
      ##Notes:
      - Incident - put into Resolve State, THEN you can use Template to stamp resolution information
      - Introduction appears on the website - with aricle links AND the summary at the top of the article BUT NOT in Service Now. SN is working to fix this.
      - Can use the Dev site to play around and learn things http://its-dev.yale.edu

      ##Questions:
      - What is Attachment link?
      - What is Designed for FPOC? = for front help desk to use, "first point of contact"
      - Keywords help with SN global search. Do keywords help with the website search?
      - How does SN parse keywords if you include commas?

      ##Suggestions:
      - "Mark Public" tooltip (hover message) = "gives article public role and then saves the article" (or more? If it does more than that.)
      - "Save and Stay" to KB article topbar.


      #Roger - Drupal
      ##Notes
      - Drupal workflow :(

      ##Suggestions:
      - Don't scare me away from Drupal too hard! lol

      #Casey's Todos
      - Work with Dorothy to get tooltips extension cross-browser, to define SN fields.
      - JS Scrolldown - anchor link
      - JS Images - Zoom Into
      Message has been deleted

      Casey Watts

      unread,
      Jan 30, 2013, 11:09:15 PM1/30/13
      to markdo...@googlegroups.com
      I would probably use separate CSS themes for different things, totally! In particular, I send newsletters to a couple of different groups, and they could each do with distinct header-stylings. It could become more useful than that too

      I'd also like to source my css from a github repository if possible. My whole team uses the same CSS as me, and I have to manually push changes to them via email currently. (although how niche is this getting? lol - it's only worth it if effort is minimal) 

      1. As for bullets, the best is probably a compromise between the two types. I really like MediaWiki's default styling for bullets. Whatever they have as their css works well for both in the internal wikis I've used at least. I don't have a good live example of effective bullets, but you can see them on this page: http://www.mediawiki.org/wiki/Help:Formatting#Text_formatting_markup

      2. That's a great trick! But I don't like how hacky it is at all. It sounds like a case for LESS/SASS you're right, but I'm not sure whether the cost/benefit is there for this today.

      3. Also a nice trick, and not even hacky! I'll try that next email I do :)
      Not widely useful enough to impose on default styling, but this is certainly worth mentioning somewhere, maybe on a wiki page? It's a shame emails don't have a standard wrapper. But since I haven't really used selection-based rendering, that doesn't affect me directly.

      Adam Pritchard

      unread,
      Jan 31, 2013, 1:33:09 PM1/31/13
      to

      Your use case is compelling. I'll certainly add this to my fantasy list of stuff to do. This is a whole other axis of compelling functionality: easy but complex email styling. It's not what I had in mind when I created it -- I just wanted to created easily create structurally complex email; advanced styling just wasn't something I cared about (beyond it being "nice and unobtrusive"). But I can see that there's a whole class of people (like you) for whom strong, varied, consistent, easy styling is important.

      I can't promise that this will be implemented any time soon, but I'll certainly be thinking about it.

      Being able to point to a Github repo (or any URL): cool.


      1. Mediawiki bullets: This looks like the styling it uses:

      ul {
        line-height: 1.5em;
      
        margin: .3em 0 0 1.6em; /* t r b l */
      
        padding: 0;
      }
      
      li {
        margin-bottom: .1em;
        /* inherits line-height */
      }

      So... A 1.6em left margin, which is smaller than my 2em and much smaller than your 3em. Line height as the primary spacing mechanism, which I don't think I like very much -- I think the space between points should be independent from the space between lines in a point. Normal line height is 1.2em, so there's... 0.7em extra space between points (I think: (1.6-1.2)*2 + 0.1). That's a bit more than the 0.5em I made default recently, and much more than the 0.2em that you use. (Please note: I'm not a CSS pro-star.)

      So... The current (new, unreleased) defaults are close?


      3. Salutation:

      Your phrasing made me realize: In some mail clients (notably Gmail, but not Yahoo) there is a "standard wrapper": *[contenteditable="true"]. You can see here that that's how the code detects a valid render target.

      That being said, I improved my previous suggestion slightly so that only the first paragraph of the first render block gets matched:

      .markdown-here-wrapper:first-of-type > p:first-of-type {
        color: red;
      }

      Note: To match, the render has to start at the top of the compose box -- it won't match if you leave unrendered text at the top. (I don't know how to get around that.)

      As per your suggestion, I'm going to a tips-and-tricks page to the wiki. And link to it in the README.

      [Edit: The first paragraph was red when I posted because I was testing the style above...]
      Message has been deleted

      Casey Watts

      unread,
      Apr 28, 2015, 8:08:20 AM4/28/15
      to Xavier Artot, markdo...@googlegroups.com
      1. You can right-click on the icon and click "options" to get to the settings page.
      Inline image 2

      2. You can then paste the css text into "primary styling css", and it should start working :D

      Inline image 1

      On Sun, Apr 26, 2015 at 12:07 PM, Xavier Artot <xavie...@gmail.com> wrote:

      --
      You received this message because you are subscribed to a topic in the Google Groups "markdown-here" group.
      To unsubscribe from this topic, visit https://groups.google.com/d/topic/markdown-here/XlsuTCHR4zE/unsubscribe.
      To unsubscribe from this group and all its topics, send an email to markdown-her...@googlegroups.com.
      To post to this group, send email to markdo...@googlegroups.com.
      Visit this group at http://groups.google.com/group/markdown-here.
      For more options, visit https://groups.google.com/d/optout.



      --
      oO oo oOo
      Casey Watts!
      Reply all
      Reply to author
      Forward
      0 new messages