Tag: greasemonkey

One of the meetup features I miss

Meetup

I will be first to admit that Meetup.com has some good features, but since they started charging the group origaniser it seems like there has been a move away from its system. The problem is where do you move to? Eventful and Upcoming are my prefered services but there are things like Zevents also. However all of them don't quite have all the features of meetup.

One of the features which I miss from Meetup is the ability to print out signs to attract people to the event when your at the actual venue. Last nights London Blogger's meetup was a small affair but attracted some regulars to geekdinner but I also finally met Jo. Jo printed out the meetup sign and placed it on the long table in all bar one, soho. I certainly miss this.

So I've decide to build a XSL transform to generate one of these for Eventful events. My first thought was to transform the XHTML page which already has microformat data for the event.. But quickly realised that the page isn't XHTML at all, for example my next geekdinner event. So unless I cleaned up the HTML first using something like Jtidy first it seemed pointless. So I started looking at the RSS and ATOM feeds. And there is where I struck gold. In the ATOM feed there is everything you need and more. Unlike the RSS feed which is simple RSS 2.0 with A9 Opensearch and Yahoo Media RSS extentions, the ATOM feed has some google data extention. The schema links no where but contains the event dates, location and more. All defined in nice namespaced elements which means its easy to pull out the data needed for the XSL transformation. I was hoping to adapt the XSL to transform not only Eventful ATOM feeds but also upcoming events. But there syndication is either ical or some odd combined html/javascript yahoo or google export. Which really sucks because its not valid XHTML. I'll post my XSL one I'm done. But I'm also considering a XSL-FO transform instead of CSS and XSL. Although its tempting to use XSL 2.0, I 'm going to resist so people can download it and apply the XSL locally. Humm maybe a simple Greasemonkey script will make this even easier to apply to any eventful event.

So using Cocoon and a simple XSL, you can now see any event from Eventful in a design which can be printed out on a black and white printer and pinned up at the event or before the event. Its not quite the table things I was thinking about before, Instead its a useful A4 poster. To use the service? simply enter the eventful unique code into the url after http://cubicgarden.com/cocoon/eventful/poster/{eventful code}. So here's a list of test events.

Please note you need to view the print preview to actually see the correct poster, because I'm using two stylesheets one for print and another for the screen. Oh and the current XSL is here. Please modify it if you feel the need, its released under a creative commons licence.

Comments [Comments]
Trackbacks [0]

Does presentation matter in a world of RSS?

So Ben Metcalfe asks the question Does presentation matter anymore? This is exactly what me, Miles, Harry and Dave talked about one night over dinner. Honestly I think it does but as Ben identifies its moved around the chain now. If we take it that RSS has a huge audience and that its not changed a lot from its current form (aka no JS, CSS, Ajax, etc in RSS or ATOM) for a moment. The presentation shifts to feed promotion and the news reader style. For example Great News which I'm using for my desktop aggregator supports CSS and I can actually define a style sheet per feed if I want to. This was useful today when Google news was delivering me all the WorldService and ArabicTV stories, as I could use the brief stylesheet to show a lot of entries on one screen. While I use the readability stylesheet for reading Ben's blog and most of RSS content.

But it goes deeper than that, design isnt just about presentation. A designer should have a hand in the structured elements of the RSS feed, the useability of how its pushed and pulled around the internet and the accessability of the feed and its content. Its what I prefer to call the whole process the Flow of the content. Its part of what I do and I feel its part of the emerging role for new media designers. I mean is it too much to ask for a designer to build a client side XSL page for a RSS feed?

Just stepping away from the world of huge RSS audiences now. There something which smart designers understand well. The media, there designing for. web media isnt print media. Sounds obvious, but were talking about the vision for how the site should look and work being thrown out the window. I'm not talking about just browser quirks, screen resoultions and font size differents. I'm talking about the range of toolbars, extensions and the like which deconstruct the website beyond the control of the tightest web designer. Then if you go down the Greasemonkey path, you have something where you can actually share your deconstructions. Smart designers understand and embrace this and actually push for CSS driven sites to make this even easier. There are a few even testing the waters with Client side XSL transformations for all content with CSS for style.

I've included a screenshot of how I currently see BBC news story pages and how its meant to look. I custom built this simple script because it makes loading up bbc news stories from my RSS reader quicker and is easier to read for myself. Others would disagree, but then I would suggest you write your own greasemonkey script.

So back to the question, yes presentation does matter and the role of a designer is very important but like everything, roles shift with the times and media. Branding is another issue which I wont go into right now either…

I found this great little post about WIndows Longhorn/Vista's redline designs. Ryan suggests Redlines are a throw back to another generation of design, and I have to agree. Dactylx asks this question in the comments
I'm down with that idea, but then how do you as a designer communicate how the design should be rendered to a developer? What can we use to replace the redlines? and Ryan replies with a slightly optimistic but good answer.

Here is the first step. Do not separate the teams. There should be no technical team and design team working separately (on different floors or on different continents). They should sit right next to each other and *understand* the problem just as great as the designers. Design is manifested in code, so if the coders don't understand, then the product is inevitable to fail.

I'm once again in total agreement, in my experience the best projects are always when everyone is involved in the problem. Not passed around like a rugby ball on a winters day.

Comments [Comments]
Trackbacks [0]