Now my calendar gets complicated.

I need to decide on a stable URL format for the DNA Lounge calendar. The new space makes things more complicated.

This is me thinking out loud about it and wondering if anyone has better suggestions that I haven't thought of.

Sometimes we have two events per day (an early event and a late event) and those are designated by the early event having "a" appended to it, e.g.:

  1. /calendar/2012/09-14a: Mortified, 8pm - 9:30pm;
  2. /calendar/2012/09-14: Hubba Hubba Revue, 9:30pm - 2am.

We never have three events per day in the same room. At least, it hasn't happened in 11 years so I'm not worried about it.

It used to be that I would have labelled those two events as "09-14" and "09-14b", but that was dumb because it meant that if we booked the later event first, and the earlier event second, then the URL for the later event had to change, and all the old links to it broke. So I had a Flag Day and changed that a few years back. Now the "a" designation is applied if a daytime event has an end-time before 10:30pm, meaning it's conceivable that we could end up booking an event after it. This is based on what we've actually seen in the real world, and now our URLs are stable.

Anyway, we're opening a new space, and so now we can permute that to four new kinds of events!

  1. DNA Lounge, Early (09-14a)
  2. DNA Lounge, Late (09-14)
  3. Above DNA, Early
  4. Above DNA, Late
  5. Both venues combined, Early
  6. Both venues combined, Late

(It is not logistically possible to run separate events in the front room and back room of DNA Lounge, or to run separate events in the front room and back room of Above DNA, so there's no need to worry about those cases.)

So I need to decide how to label those URLs, and I'd like to get it right the first time so that I don't have to break URLs again later.

So far I'm toward using "c" and "d" for #3 and 4 above, and treating #5 and #6 as synonyms for #1 and #2 (meaning: a four-room event looks, URL-wise, like a DNA Lounge-only event where Above DNA is closed). (The "b" is silent.)

I'm not crazy about the "c/d" thing because it means that URLs for every night-time stand-alone show in the Above DNA space -- which will be by far the most common case up there -- will look like /calendar/2012/11-09d.html, and what's that "d" doing there? It's just kind of a wart.

I do want them to be the same calendar, and not living on two different web sites, because we're branding it as one venue that has two performance spaces, not two separate venues. Also, every Saturday night, Bootie will be in both rooms, so right off the bat we're running "combined" a large chunk of the time.

Any other non-warty suggestions?


The other thing that really bums me out is that I think it means my calendar can no longer be a Cartesian grid. I was really pleased when I figured out how to make the calendar resize when the window is resized and yet cause all the cells to remain square. Because calendar cells should be square, dammit. When there are two events on one day, it splits the cell vertically. But now there are potentially four events on the same day. How the hell do I display that and keep the cells square and the text readable? I think I can't, and I'm going to have to make the "week" lines be two lines high.

I do not like that.

But I also don't like having two grids, one for each room, and that's pretty much the only other option. (A vertical split would not play nicely with text wrapping.)

Any other ideas there?

Tags: , , ,

31 Responses:

  1. KevinW says:

    I guess I would treat above-ness and early-ness as tags which are by default absent but may be added explicitly. And denote them with a -above and -early suffix resp. So your 4 cases are

    1. 09-14-early
    2. 09-14
    3. 09-14-above-early
    4. 09-14-above

    Advantages: case 2 is unchanged, the URLs are human-readable, and the month/day/above/early fields can be parsed by tokenizing on dash. Disadvantage: verbosity.

    • jwz says:

      Well that's exactly what I described except I used single letters, "a" = "early" etc.

      • KevinW says:

        It sounded to me like a-d is a single field of 2 bits i.e. an event has exactly one letter and b is silent. I'm proposing a system of 1-bit tags. Which is indeed indistinguishable when there are 2 properties, but could be expanded gracefully if you ever need to add another property.

  2. Rob says:

    I'd be a big fan of /calendar/2012/09/14/[early-|late-|][Above-|]DNA[-Lounge|]-Event_Title.html

    But I'm weird.

    • Ewen McNeill says:

      I think the idea is to have something stable/predictable that doesn't involve anything a promoter might change, and ideally that means that repeat events have the same URL but for date. So I'd leave the title out of the URL; it could always be a separate index page for regular events, with links to each date event.

      But apart from that, I'd tend to use a URL like that too:


      Possibly with some variations in the brackets (those were just the first that came to mind). The day page could then be an index/grid for what's on that day, with links to each one.

      Another option would be just to do the day index page thing, and use #eventname (or #venue-time) to go the right one. If the event name changes then the link still mostly works, give or take a bit of scrolling.

      But really any of the options proposed so far is vastly better than the Web 2.0++ totally random URLs that are infesting the web these days.


      • MattyJ says:

        I was also thinking along these lines, except even simpler. You basically have four slots that could possibly be filled, maybe or maybe not by the same event taking up two slots at a time. Have the possibility of these URL's for any date:


        If an event takes up the early and late slot at DNA, then put the same thing in the two html files with the actual times of the event since times are not displayed on the calendar, anyway. 'cp early.html late.html', easy peasy. It would be easy enough to move events to a different date or time.

        Replace the current 404 message with something along the lines of 'no event scheduled at this time'.

        The second question is a stickler. Hard to figure out how to cram four events in there unless you give each one just one line. As it stands now, split days in my browser cut any third line off anyway. Either that or start abbreviating everything and have some sort of hover-over pop-up. But that's kinda stupid. Maybe start selling advertising on your calendar and whoever pays the most for the day gets the most visibility? (kidding. sorta.)

  3. Roger says:

    Could you not use the event name instead of meaningless suffixes? eg /calendar/2012/09-14-mortified and /calendar/2012/09-14-hubba. That avoids any issues with rooms, or of the URL changing should the event time change.

    Amazon also do a nice stunt with their urls that could be something like /dp27131987/Mortified@DNA:2012-09-14. The /dp.../ bit is a unique id, and everything after it is completely ignored so anyone can put anything there.

    • jwz says:

      "Add meaningless fluff to the end of the URL" does not actually solve any problem I'm trying to solve.

      Event names change.

      • Roger says:

        As far as I can tell you are looking a cosmetically nice permalink for a single event.

        The unique id followed by ignored text will work just fine with names, dates and/or times changing, as well as cancellations, although the id won't be predictable. And the ignored text lets you make it as cosmetically nice as you want.

  4. Mike Damm says:


    Include the start time of the event in the URL. I suspect you won't have two things starting at the exact same time for logistical reasons. If it does happen you can hack one to start at one minute after. Days can 302 (Moved Temporarily) to the first or featured event of the day.

    • jwz says:

      No, we definitely will have two events starting at the same time because 8pm, 9pm and 10pm are just normal times when people expect things to start. Also, start time is something that very often changes between when an event is booked and when it actually happens.

      • Mike Damm says:

        It sounds like the problem you are trying to solve is "what about an event does not change." Once you can answer that question (even if it ends up being an "event ID") you'll get the URL properties you're looking for.

  5. tew says:

    Do events ever initially book as a single-room or combined event and then switch, after the extent of public interest becomes apparent?
    When events are cancelled and replaced with a new event in the same space at the same time, should the URL change?

    Since you're actually booking these things, you're paid to think about what room and what time and all that. The attendees just want something they can post on their facebook wall (or whatever cool kids do) that will always point to the correct information about the event they cared about, no matter the details of the room/time. That's going to probably look like a unique id for each event.

    • jwz says:

      You make a good point that I'm the only one who really cares about what room things are in, and the outside world just cares about the event itself. If an event gets upgraded or downgraded from the small room to the big room, that probably doesn't matter to most people.

      However, I'm not a fan of URLs that have a random "ID" number in them. That's the obvious solution for people who have databases on the brain, but I think it's far better for URLs to be short, predictable, human-readable, human-editable and most importantly, easy to type if you happen to see them printed somewhere unclickable.

      • zompist says:

        I'd abandon the last clause, since you've lost most people with anything after "". How many people can even spell "calendar", much less realize that the last letter is a code?

        As a programmer, I find one-element-per-field codes easier to remember, so I'd add a letter for Above DNA. So instead of a / _ / c / d I'd use a / _ / au / u. That's easy to remember: it's "your current system, plus add u if it's Above DNA."

      • Jon says:

        I'd go with tew's proposal, but choose the IDs similar to your original approach. Keep your /calendar/date scheme and add letters (a, b, ..) in the order that events are booked. I don't think anyone looks at the URL and thinks "oh, there's an 'a' at the end, that must be a DNA Lounge early event." So giving those letters a semantic in terms of location will not serve anyone except maybe you. Simply add 'a' for the first booked event, 'b' for the second and if the events ever happen to change location it doesn't affect the URL. If one event gets canceled, oh well, that letter won't be used again for that day.

      • As a compromise you could make you 'ID's meaningful. Create a unique code like BOOTIE74 when you make each event. It's especially easy to type in from print material if you have URLs like:

        With the autoredirect to canonical url you can print-publish the short version and web-link the long version (with all the SEO crap).

  6. Ryan says:

    Should be an index page instead of one of a potential few shows. If there is only one show, then include the content of that show's page as normal. If there are multiple shows, either stack them on the page, or link away to sub-pages, like 9-14/bootie.html. I get why you can't rely on names to stay static, but you could set up a rewrite rule to redirect changed shows (and bogus links/typos/etc) to the index page for that date instead of dying completely. Added bonus of having more human friendly and semantic urls, while still retaining a clean and canonical base. If you're completely adverse to names in the url, the indexed links could be your letters instead, but I think the base date url conditionally showing the single show or links to all shows is a net positive. Plus, if someone doesn't include the letter, a mistaken or lazy link to the index page let's you still serve the visitor what they were looking for (while also possibly increasing exposure to other shows).

    This also makes digging backward in time simpler. You don't have to guess and check letters or other suffixes in a url to find out what else might have happened on that date.

    Calendar grid is tough. Pure css offers no good solution I can think of, other than setting the overflow content to be positioned absolutely over another day on hover or something. Awkwardness is possibly mitigated if the calendar cell links to the overview/index page as above....

    You could alternatively just list the events shorthand in the cell and do a more complete overview in a light box or some other overlay. Also, you might gain some extra vertical space if you either float the date into a corner, or blow it up and make it tonal and just flow text on top of it. You would need something like fittext.js to do the second option in a reliably fluid/responsive way.

    I'm not sure how you keep the squares without turning each cell into a slider/fader if there's multiple events.... Or have a toggle on the page that switches upstairs/downstairs into the same cells, which defeats a lot of your intentions.

    The only other thing coming to mind so far is probably slicker than you'd like, but you could do something like:

  7. NotTheBuddha says:

    My calendar grid suggestions:
    On 4-event days, run the date cardinal as a leading superscript or eliminate it from the cell entirely to be picked up form context or the click-through.
    Keep the daily cells square and drop the divided outlines, so you can have 8 lines of height, 2 per event.
    Abbreviate "all ages" as "0+" or something else short, so any given event's age limit takes up at most 3-4 chars.
    Regardless of event qty, link the entire day's cell to a page with that day's events in more detail, and then to the a-d business if still necessary.

  8. Wobbly Wobbly Widgets says:

    I like the multiple-flags approach, but I'd make them all single-letter flags and just tack them on in alphabetical order (like object flags in fbmuck!). Obviously the flag for “uses second space primarily” should be “e”, for “elevated”, and “a” can mean “ante” for backward compatibility, and keeping this distinct from “early”/“above” is just an exercise for the reader…

    (You could invert the sense of the second flag for future events, say creating “g” for “ground”, but if the lower area is externally perceived as the “primary” one then that seems slightly worse even if it would make the most common case be the shortest length.)

    I think visitors who care about URLs at all would be able to figure out that the extra letter refers to the upper space; the distinction between “e” and “no e” is easier to see than the one between “a/c” and “‹empty›/d”. Longer tags would have a noticeable increase in length and inconsistency, and wobbling URLs around based on surrounding events to minimize length (disambiguation-only tags) seems like it would make you sad.

  9. Jeff says:

    I believe what you came up with is the sanest approach which also results in the least amount of change to the existing system. That said, having five and six be synonyms for one and two will break if you ever have an event that was supposed to take up all of DNA but needs to be split for some reason. Is that even a possibility?

    • jwz says:

      Well, such an event would never be "split" into two events, it would just contract, freeing up the other room for something else. Also it's unlikely, since if we booked both rooms we'd be pretty sure that the event was going to be huge.

      • Jeff says:

        Yeah, "split" was the wrong word. If you won't ever see an event shrink from two rooms to one, I don't believe the c/d scheme can be improved upon.

  10. Stephen Harris says:

    If I've understood your desires properly, I think a slightly _less_ optimised version of what you were thinking of is better. You have two locations: (a)boveDNA and (d)NA and potentially (b)oth, and two starting windows (e)arly and (l)ate. Thus I would flag each event with a two letter code ae/al/de/dl/be/bl. Every event has this two letter code. What you proposed is very similar to this, but you optimised out the code tags in your common use cases. I would argue that maintaining consistency is better aesthetically because you don't end up with odd warts (some events with letters, some without; also a potentially common perception of using single letters as a sequence identifier, rather than a time/location identifier so the silent "b" feels ugly).

  11. Tom Lord says:

    This is a URL suggestion. I mainly wondered what people should get if they just type in:


    and thought that should be an index of all shows booked for that day. So, overall:

    Events get names like these (verbose but self-explanatory):


    These others are "index" URLs. They list all applicable shows or, if the list has exactly one element, they can redirect to that show page:

    /calendar/YYYY/MM-DD/house ... an alias for /calendar/yyyy/mm-dd

    • Tom Lord says:

      Further, if a show definitely takes both the early and late slots, it can just be a show:


      and if you want smaller URLs, these aliases would work:

      above/early-show == a
      above/late-show == b
      above/show == ab
      lounge/early-show == c
      lounge/late-show == d
      lounge/show == cd
      house/early == ac
      house/late == bd (heh)
      house/show == abcd

      Hmm. I wonder if you'd ever want to book both an "a" and a "bcd" event (e.g., "a" for a private party before a main event takes over the whole place).

      And, every unassigned show URL could be usefully aliased to one of the index URLs.

  12. Make the calendar date part of the URL irrelevant; it's just there to make the URL meaningful to humans and search engines:


    The server only looks up {eventId}. Its first act is to compare the submitted URL to the 'canonical' URL and issue a 301 (permanent) redirect to the canonical URL. This handles the case of renames or date changes; old URLs and misspellings do "the right thing" as far as users and search engines are concerned.

    Personally I would use the more REST-ful /event not /calendar for the actual URLs to events. And I'd probably use /event/id-date-title. But I can see why you would want /calendar/date/event if the user can chop off parts of the URL and get events for a particular year or month... presuming your audience is technically savvy enough to manipulate URLs.

    We deal with this a lot, try this:

    • Thomas Woolford says:

      I'm a bit late to the party, but this is definitely the best option. It allows you to have easy canonical urls with meaningful keywords in the url that you will never have to re-architect whenever you add a 3rd show to the lineup. just because it never happened before, does not mean it will never happen.

  13. Bellfry says:

    Regarding the calendar grid: can't you just split cells vertically by three/four and use :hover and z-index to give the user more info? It could look like this:

    Somewhat crammed, but it should still work.

  14. Approaching this purely on a user side, the website answers the question: "What's going on at DNA today?"

    To me that means a page to list all the events on that day, then a detailed page of that event. All agnostic to the physical space as it's a listing of the day's events at DNA.

    The events getting "a", "b", etc would be a first booked, first served bases. While there will be scenarios where the "a" event is after the "b" event, the actual user interaction wouldn't matter on a URL perspective. The key would be the day's page when there's more than one event to display times accordingly.

    In case of days where there's only one event, the day's page can either redirect to the "A" page.

    (( Saw that Ryan has a similar point to mine, but with lettering rather than naming for file names. ))

    • David M.A. says:

      Maybe I'm missing something, but why have the ~/calendar/2012/09-14/ url be an event at all? Start on ./a and use ./ as a round-up link, for all events that are happening that day.

      Unless we have to maintain backward compatibility.