Yeah, I have no clue why people feel the need to combine words for the sake of marketing either. Pingilactic sounds like something that happens to your nipples when you don’t change the oil regularly. Or something. Anyway, the masterminds behind this new word for 2008 are Profilactic and Ping.fm. Profilactic I’ve mentioned before, but Ping.fm was a new one.
Trying to create order in the increasing chaotic sphere of the social web is getting considerably harder, not easier, lately. This is surprising in a way, but when you consider the number of competing services coming out, and quickly changing features, it’s hard to marry yourself to one brand. But the past several days my corner of the web has seen a lot of chatter amongst people about Twitter’s trouble with scaling up to meet the service demands. This flagship Ruby on Rails application has been struggling with problems in their architecture that is hindering its ability to meet the increasingly heavy demand. There are a handful of us who have been playing with a new competitor in the microblogging realm called Plurk.com. It’s one of the dumbest names I think they could come up with for a service, but the site itself is pretty neat. It boasts the same 140 character limit, but has some natively supported action verbs, threaded discussions, a neat timeline, friends and followers, cliques, and nice privacy features. The largest complaint is that it lacks the support that Twitter gets from people developing things like Adobe AIR interfaces using Twitter’s API (Application Program Interface). So far, I don’t believe Plurk has opened their API, and that’s a shame. And more to the point, there hasn’t been a way to kill two birds with one stone and post to Plurk and Twitter together so that one doesn’t have to alienate an established group of friends to switch services. The ideal solution would be something like an AIR application that can monitor and post to both, so that you can keep your friends wherever they might be, but not double the effort to keep your thoughts up to date.
Okay, moving on in the same vein. A similar conflict also came up between the options of using FriendFeed and Profilactic. Some of my friends are on one, some the other. Like Twitter and Plurk, those that have chosen their side are pretty married to it. I’ve been using Profilactic in part because it supports a HUGE number of services, and I like the sidebar widget it creates (that integrates nicely with Wordpress). But, it seemed like more people I know use FriendFeed. Ahh challenges. I discovered the easiest way to solve this conflict was to push my Profilactic lifestream RSS to FriendFeed. So, one down. Sadly, the Plurk/Twitter deathmatch can’t be solved quite so easily.
Now, let’s bring this all home. I ended up spending some time going around all four of these services, looking for answers to the question: what to pick? The Profilactic/FriendFeed debate was simple, since the idea of a Lifestream is pretty straightforward, and RSS is totally portable. Subscribe to either of my accounts, you’ll get the same information. Part of what convinced me to kick FriendFeed into the #2 spot though was what I mentioned earlier, Ping.fm. Ping.fm has partnered with Profilactic to allow you to update supported services from you Profilactic lifestream page. This is cool, because it helps address the problem of updating several microblogs at once. It’s not exactly what we had been seeking, but it was an answer nonetheless.
Ping.fm supports many different services, and groups them by things like status (Facebook, MySpace), microblog (Twitter, Plurk), or blogs. Selecting the group and posting will send your update to all services in that category. With the partnership, this functionality is now exposed to you right in Profilactic on your lifestream page. Ping.fm is addressing a central problem of how do you easily update everything you’re in. I tried to tackle this a while back with Netvibes, but it is surprisingly hard to do since you can never be sure just how much a company will expose in their API (after all, they still want you to go to their site). Ping.fm is still in beta, and you need to be a member of Profilactic to sign up (or I might let it slip that “profilactic” is the signup key. Oops). As it is, Ping.fm is FAR from the holy grail of social web updating, but it has the right idea. It doesn’t have great handling of services’ custom features (Plurk default verbs for instance), and it doesn’t seem that you have a way to control how it groups services. Mostly, it’s pretty basic and simple, but it does work.
Hopefully, assuming they are paying attention to how people are using Ping.fm, I suspect they will work to make inroads on some of these ideas. At the moment it seems like the best option if you want to try and address several sites all at once though. Then again, it’s a little like using Pidgin or Trillian for instant messaging, where the cost of merging services is losing features. And as a corollary, just because you update several services at once doesn’t mean you escape needing to read several sites to keep up with replies. You still need to go to Plurk for threaded discussions, and Profilactic doesn’t necessarily keep up with Twitter’s @ replies.
Ultimately, I think it’s just a matter of waiting. Ping.fm is a solution, if you really aren’t willing to double up some effort. Given time, I think Plurk will open up, and I think that Plurk and Twitter have enough in common that someone (smarter than me) will be able to make one application that will handle them both simultaneously. And even though Plurk is neat, there are a whole lot of people in love with Twitter’s simplicity, downtime or no downtime. It’s up to the services in the end to provide the APIs necessary so that we can use them the way we want. But, such interaction is a privaledge, not a right, so we just need to suck up to the developers of our favorite services.
Explaining Profilactic’s new “Post something” feature from sMoRTy71 on Vimeo.
This is very short and simple. I got an idea for a new Wordpress layout, and I want to get some feedback as to your preferences for the structure, assuming you were either designing or reading a site based on the structure. Traditionally, we see a lot of left hand navigation elements on the left side of “normal” websites. Blogs tend to favor the right for sidebars. In this layout I’m plotting out, there will be an “aside” type element that I do not want juxtaposed against the sidebar area, but I also don’t want it hanging free against the right side of a center aligned page because I think it reduces the readability of it. So the options I crafted are as follows.
Option one is a left aligned page, with a left hand sidebar area with the asides floating on the right of the content. Option two is a center aligned page with a right hand sidebar area that allows the asides to come in on the left of the content. Both of these examples are optimized for 1024×768, but I am toying with the idea of making them full width, or possibly flexible width (though I generally find that harder to get “perfect”). Click either thumbnail to view an actual sample page. I welcome the opinions of both designers and random people alike. Also keep in mind, this is just for planning the basic wireframe of the site, it has nothing to do with how the final thing will actually look, from a “pretty” point of view.
Polls follow after examples.
Having been moved into the marketing department at our university, it has afforded me the opportunity to attack some different problems from a new angle, and it has also allowed me to engage some ideas that had been floating around that weren’t necessarily an appropriate goal while in the IT department. Something I am coming to realize is just how different web marketing is from the garden variety, and how it is viewed and approached by those who need it to be successful these days. The reason the web office was transferred was to make the goal of the site redesign easier to achieve, connecting us with the tools and resources that would make this happen. While I firmly believe managing large web sites is worthy of its own, autonomous office, it’s easy to see why a lot of places are beginning to rely heavily on their marketing legs to Get the Job Done.
When you compare Old and New Marketing, there’s one distinct difference. Old Marketing was a passive attack. You gleaned information that you could get about your target, crafted a message, and tossed it out there, hoping it would stick, thinking you might catch a fish once in a while if they were in the biting mood. This is very passive (not to mention boring, and smelly). But on the whole, that’s how any kind of TV ad, radio spot, newspaper slot, or magazine fold out worked. Hope. The New Marketing that is coming to the forefront is more like a smelly hobo (clearly smelly is just part of the job) that assaults you on the street, screaming in your face and peeing on your shoes. Sure, they might call the cops, but once in a while they’ll give you a buck, or a half eaten sandwich. The difference is, this is active. With the web, you have the opportunity, even the expectation of interaction.
What I find interesting, particularly in our case, is how often web professionals are being relied upon not just to set up and maintain a site, but to also provide insight into marketing techniques. It’s similar to the case of: “Oh, you fix computers for a living? Will you come wire up some light switches for me some time?” (for the record, no, I won’t. 120AC has blown me across a room one too many times). Because we understand the web, we are seen as a resource for determining what is successful for web strategies in marketing. This reflects largely the effect that marketing training has had on the professional population, if it was learned outside of about the past five years.
It’s much more recently that web marketing has gained ground in academic disciplines. That is to say, it’s a must-know subject if you study marketing in college now. Previously, not so much. Even here, marketing students are being required to take rudimentary classes on page design (even though I hear rumors that they are being taught that Frontpage and frames are the end-all and be-all. And Jesus wept…). But students benefiting from this are just now starting to hit the job market, and are hardly dropping into positions to manage web initiatives out of the gates. And even if they are, they know just enough to be dangerous, and way more than enough to be frustrating. So for the time being, us web geeks are the fall back point.
What’s funny is that I don’t think that’s bad. Let’s face it, to be good at our jobs, we are forced to keep up on cutting edge tech, learn how to leverage third party APIs, and understand what people find usable and beneficial. In a way, we are the unofficial web marketing foot soldiers. Web work is one area where you can’t necessarily afford to be behind the curve (often, you’re better off not getting on the curve at all if being behind is the other option), and for marketing professionals whose focus is not 100% on the web, they can’t be expected to know just where in the pool to jump in. We tend to be much quicker to absorb concepts like video editing, sound bite assembly, photo slideshows, and all those techniques that used to be attached to broader, passive media. It’s frequently easier for us to learn about how to place that into social media than it is for a pure marketing person to figure out social media and how it relates to traditional media. More work? Yes. More responsibility? Yes. But all this also makes us a much more valuable resource.
So to those that have been like me, where you might think Marketing isn’t a good place for a web team, keep in mind the value that your skillset can provide, and why such a close proximity can be valuable. Obviously, I still believe that a well poised and staffed web office should be the ultimate goal, but in higher education, such a team is more of a luxury that most places can afford. Instead, we get a few hobos together on the street, and send them out to pee on a few shoes. But ultimately it gets attention, and more often than not, it can get results.
After about a year, I am kicking Drupal to the curb. I fully recognize it is a robust, capable CMS (Content Management System). So are a lot of other systems. But it’s just not fitting me well. Sometimes I think CMS usage is as much about tastes as it is strict functionality (actually, I’m sure of it). Sure, a sweater might be warm, but if it’s ugly (with a big clown on the front), you might wear something a little lighter for the sake of having something more appealing (and less clowny). That’s where I am at. I’m tired of clowns and sweaters.
I originally adopted Drupal to run Penpedia when I launched the site for a few reasons. One, about that time I had started getting into Drupal just through the course of investigating different CMS’s. I did like that user accounts could have their fields customized. And I found a module that allowed for hand in hand single sign on authentication with the other half of the site, which ran MediaWiki. That also made it appealing. The longer I used it though, the more the rough edges started showing.
First, I didn’t want to start writing templates for a new system. This is in part because I already know how to template other systems like WordPress, e107, dotCMS, and a couple others. As a result, I start losing patience for learning others. Not a huge deal, because theming Drupal isn’t terribly hard, it was just that I didn’t want to. The theme I ultimately grabbed was only marginal, but I just never got motivated to write a custom one. And frankly, I’m a little ashamed of that, because the design of the site is not indicative of my abilities. But what did drive me nuts was the lack of any WYSIWYG editor built in. And the module that enabled the feature was disgustingly complicated, and caused a lot of clashing with the code stripper. The added steps of permissions and profiles for it to work right was just way beyond necessary. Which leads me to the next thing. The permission system didn’t please me. It didn’t work how I’d expect, and seemed far to complicated for what it was doing. That’s what I love about dotCMS, you can’t beat their permissioning system. Doing complex, and sometimes even more routine, tasks in the back end of Drupal generally felt like a power struggle between me and the code, and I loathed the idea of having to go in and tweak anything. And just to round it out, I’ve never liked the “node” concept.
But, just to remain clear, if it works for you, then great. It just hasn’t meshed well with me, and has actually discouraged me from developing the site better. That’s why I plan on changing things over there to Wordpress later this week. The MediaWiki portion will remain unchanged, though there might be some tweaks to login stuff, as I am investigating what needs to happen to maintain single sign on with the two. Plus, between here and there, I’ll only have one software package that I’ll need to worry about now, as opposed to two, which should encourage more development and activity on my part on the Penpedia site. I think this will be a move all for the better, and it should benefit the site well.
The moral of the story? There is a lot of value to standardizing on a CMS, and sticking with what you know. Even if a system isn’t perfect, if you are familiar with it and know its capabilities, I think that beats out picking a robust system that just doesn’t click for you.
With the release of dotCMS 1.6 came one of the more anticipated new features in recent months, their new “social” calendar system. This calendar represented a noted improvement over the previous event portlet (though the event portlet still exists for some additional functions, like scheduling and managing conferences, etc). This new calendar makes use of a portlet to manage the system in the backend similar to the old event system, and builds out on the front end through a combination of Velocity, .vtl files, and some layout bits. It also creates event entries as content in a structure, so that it can be queried and pulled no different from any other content in the system (note that you might want to make sure that you don’t currently have structures called “Event,” “Building,” or “Facility” already, as it will want to make them if you are upgrading. New installs obviously don’t need to worry about that).
If you want to take a look at the calendar first hand, you can see the example that is up at the demo site, at http://demo.dotcms.org/calendar/. To access the back end, login to the admin console by going to http://demo.dotcms.org/c and plug in the user ID test@dotcms.org and the password test. In there, you’ll see the tab for “Calendar” that you can click on that will take you to a similar, but stripped down looking version of the calendar. I’ll be using the demo’s site front and back end when describing features, and in the video below.
Part of the major improvement with this system is that as opposed to the event portlet, it provides true calendar functionality, whereas the event system provided more of a list view, regardless of how you tackled it. This calendar is very AJAX (Asynchronous Javascript And XML) heavy, and thus can present an accessibility problem by default, but since all calendar events are simply structured content, you can very easily create a standard HTML based variant for users with special screen needs (and really, do you know a calendar that is truly 508 compliant out of the gates in the first place?). Storing events as structured content gives you an extra layer of control over the presentation of those events, control that is unmatched in other calendar systems. The interface itself is fairly smooth and intuitive, without a lot of tricky links, or confusing navigation (I’m look at you, Active Data Calendar). Though fairly simple in terms of usage, the fact that everything just works, and works like it should, carries a high value. And in keeping it simple, it is actually a very powerful little tool.
The calendar itself supports all the traditional types of functionality: Time, date, place, multi-day, all-day, list-week-month views, RSS feeds, detail view and searching. Additionally, you can add events from the front end (if enabled), tag events, filter by tag(s), filter by calendar(s), attach files and images, provide detail popups, and provide automatic integration into Google Maps. Using categories, you can effectively create completely self contained calendars of different events, and one event can exist within multiple calendars simultaneously. All in all, it’s a pretty nice feature set. It will also save you trying to integrate with a third party calendar for your business that would require and supply it’s own login, back end, and functionality challenges. With some CMS (Content Management System)’s, they might have a calendar, but it’s an additional install, plugin, or module that you have to manage. dotCMS includes the calendar out of the box (still free), and if you don’t want to use it, you just don’t display the page in the back end, so there’s no extra labor involved. Other enterprise CMS’s come with built in calendars, but you’ll pay dearly for those packages.
The primary challenge right now is that if you do not load the starter site, or are upgrading from 1.5.x, you don’t have all the front end files (not to be confused with the back end admin portlet for the calendar, which is totally there whether you upgraded or installed fresh and will be in need of no special attention) that you’ll need to display the calendar (this will be changing soon, however, as I understand they plan on bundling all that with the CMS so you’ll have it if you upgrade or don’t use the starter site). What I did to solve this problem was to go to the demo site, and lift all the files out of their /calendar directory. This had one disadvantage: all the files are hardcoded to the /calendar directory. So, what I have done is taken all these files, and modified them so that you can upload them into your system, and they will adapt to wherever you want to put it. Just download this zip file which contains everything needed to display the calendar to your visitors, extract it, and upload it either with the multi file uploader or over WebDav. The only other thing you need to do then is make a page in whatever folder that will be your calendar, let’s just call it index.dot, and place the following code into a piece of web page content that you use on the page:
This will load and fire off all the rest of the Velocity templates. There are two CSS (Cascading Style Sheets) files (grids-min.css and reset-min.css) that are needed because the calendar was designed with Yahoo Grids, and those styles make sure everything lines up properly. A third CSS file (cal-base.css) that is included is the base starter site CSS, and you could remove it as necessary to meet your styling needs, but I included it at the moment for the sake of appearance reproduction. All three CSS files are included in the zip file above already, and you’ll see them referenced in velocity/calendar.vtl. Using the files from the zip file, and the content above, you now have a calendar that you can move to a new directory should the need arise, or should you simply not want it in /calendar. If you move it, just make sure you change the /absolute/path/to in your piece of content to point at the new location of the load-calendar.vtl file. You could even make that portion dynamic if you wanted to, simply by removing the first line from load-calendar.vtl, and adding it to the content, making it:
The only reason I didn’t do that by default was so that way you never have to copy and paste that set() from here (since I can’t “include” a piece of content in the zip file), and to keep the information going into the content item that tells it to make the calendar as simple as possible. Odds are, once you place the calendar, you won’t be moving it around anyway. But this way you don’t have to change all the paths yourself, and you aren’t locked into using /calendar.
Below, I have included a brief overview of the new calendar, so that you can see some of the functionality and how it all comes together.
Download the customized dotCMS social calendar front end files (.zip, 131KB)
Posting tweet...