In Valid Logic

In the newest version of Telligent Community and Telligent Enterprise, we’ve completely rebuild the way email templates are handled to unlock a new level of possibilities and performance. I’m planning on going over several aspects of it, including highlights, usage, and extending the new templating with a series of blog posts.

Up until now, we’ve always used the build in System.Net.Mail.MailMessage support which is baked into the framework. While it has served us well, it had a couple of limitations that we had been bumping up against in trying to grow Mail Gateway’s functionality.

The new templating is based on nVelocity templates and borrows a lot from Graffiti. If you’ve ever created a Graffiti theme or written a Chalk extension, you’ll see a lot of similarity with the new templating. With the messages now, you actually generate the raw MIME messages. MIME stands for Multipurpose Internet Mail Extensions and it is the standardized format of email messages. By working with MIME directly, aided by a series of helpers, we are able to control aspects of the message in a fine grained manner.

First, in ability to control who we’re emailing independent of the message headers. With email, who the message shows in the To headers who it isn’t necessarily sent to, such as with mailing lists. Previously, Mail Gateway always sent the messages to the user, from the sender, and with the list as a special “Sender” header. This is how messages showed up in Outlook as from the user “on behalf of” the list. This type of set up didn’t work well with all client, particularly the iPhone. The iPhone would always reply to the user who sent the message, not the list.

Building on the last point, since we couldn’t set who a message is to independent of the message, Telligent Community would have to generate a message for each person it was emailing. So if a forum had 100 subscribers, when a new post is made, it would generate the email 100 times, queue 100 messages, and then send it out as 100 individual emails. With the new handling, we can actually generate the message just once and have it go to everyone in one swoop. Also, since mail servers often limit the number of recipients per message, we can take that message and configure it to allow 20 recipients per message. So instead of sending 100 messages, we could safely get it down to just 5.

Additionally, the variety of messages can be greatly expanded. It is now super easy to include an HTML and a plain text version of the body in the same message, then allow the email client to chose which one it will show based on its preferences. Or we can generate both at once, and then chose which one gets sent out after wards depending on user preference.

With the old support, we didn’t have the ability to support subsets of functionality like meeting requests. Meeting requests are basically an attachment with the ical event, and special headers indicating a response is supported/expected. With the built in functionality, Mail Gateway could read the attachment, but not handle or send it back out as a meeting request. We still haven’t added this functionality, but now the limitation from MailMessage is removed so we’re one step closer.

And finally, the old templates were limiting with what was available within messages. You only had a fixed set of tokens that could be used within the email, such as [SiteName], but it was really limiting in additional fields or field manipulation. Do you want to change the format a post date is displayed in? Want to only show a certain excerpt of the post body? Want a field that wasn’t available in the standard set? These things would often require code changes before, but now with nVelocity templates, you actually get the Post object, not just the common post tokens. Want to change the date format? Just use $post.PostDate.ToShortDateString(). Want the post author’s display name? Use $post.User.DisplayName.

Aside from new functionality that is enabled, there are several benefits to what we already use emails for.

First, email templates themselves are greatly simplified. You no longer have a gigantic XML file with all templates, they’re now template-per-file. Templates are no longer in XML, so you don’t need to worry about escaping certain characters of using
instead of
or using an amperstand (&) or other characters that need to be escaped in XML. These minor things often confused users who didn’t know about XML, or even seasoned developers who had a knee-jerk moment.

Second, when you need to do something more complicated, there are now some solid extensibility points. This makes it much easier to integrate advanced functionality in a simple way.

More advanced pieces of email generation is now simpler to test. With the extensibility, code is compartmentalized and easier to break down and test certain subsets. Additionally, we also plan on making it easier to unit test specific email templates, to ensure the template is rendered without errors and with the right content. I’ll be covered the ways to extend the templating in upcoming posts.

Finally, for portions like forum notifications, the number of messages generated is reduced which helps to improve overall performance.

In the next post, will give an overview of ways to extend the functionality of the templates.

Today, all the Telligenti have been buzzing regarding the recent release of Telligent Community and Telligent Enterprise. From telligent.com:

"Telligent, a leader in community, collaboration and social analytics software, today announced the availability of version 5.0 of Telligent Community (previously Community Server) and version 2.0 of Telligent Enterprise (previously Community Server Evolution). The latest versions of Telligent’s community and collaboration software represent the company’s ongoing commitment to innovation and enterprise collaboration."

Finally, after months of feverish development, we’ve reached the point of a release for what is probably our biggest release in history. Our v5.0 is unlike any of our previous major releases. We have a completely new permissions system, revamped groups, new search, new email templating, and new widget based theming.

Soon I’ll be having a series of posts going over some of the bigger technical points in some of my areas of expertise. In particular with this release, I’d worked on the search implementation and the new email templating.

In previous versions of CS, we had two implementations of search, the default Search Barrel and the more powerful Enterprise Search, which was built on Lucene.Net. Now, we’ve changed the search to be much easier to extend and change out. Previously, search was tightly coupled to the index. You couldn’t easily add new types to Enterprise Search or index additional fields.

Our new search is comprised of a series of mappers, which define how to convert an object into a searchable document, and define your own content handlers, which are used to grab objects that need to be indexed, have them mapped, and passed over to the index. You can easily build on top of existing mappers, create mappers for new types, and add new content handlers to the search process. Additionally, the search is broken out into indexing and search, allowing you to easily create your own implementations. Our included implementation is now based on Solr. Why Solr? A better question is why not Solr? It did everything we wanted and then some. It is feature packed, high performance, and super reliable. With it, we were also able to easily build in thread collapsing. Tired of the search results all being messages from the same thread? Now we can collapse down the results, combining all the posts from a single thread into just one result.

What’s new with emails? Over time, we found the old email templates to be too limiting. We had one big XML file containing all the emails, people often ran into confusion when editing HTML emails (since they had to be XML escaped), and the default tokens were limiting depending on the types of customizations you’d want to make. Our new emails are entirely based on nVelocity. If you are familiar at all with the theming in Graffiti, you will be right at home in the new email templates. The templates produce the mime documents that get sent out, allowing you do manipulate the message headers, attachments, and body content. Instead of providing a fixed set of tokens like [PostDate], you get the actual objects. You can now use $post.PostDate, or call $post.PostDate.ToString() and pass in a custom formatter. Want to do more? Can easily create Chalk modules to add new macros, or TemplateModules to manipulate the nVelocity context before templating, or the processed mime object after processing (useful for adding binary attachments and such).

Want to know more? Keep posted.

I frequently read stuff on WebHostingTalk. Yesterday I was catching up on the happenings of the week when I saw a post of a type I’ve seen elsewhere before. The premise is “we’re a software development company, we’re writing this product, what do you, our target customer, want in it?”

I always see those types of questions as a danger sign.

First, you should already know your customer base. Would you want a company who has no idea about taxes writing accounting software? Hmm. Maybe this way… would you want an auto mechanic who was given a manual on heart surgery to do your bypass? You, yourself, cannot solve a problem unless you understand the problem.

Working with a target audience is good. However I’d argue, show them something and ask for feedback, don’t just ask them at the beginning without having anything to show. Also, narrow down who you ask. If you ask the world, you will get inundated with responses, but how to do you know the quality of those responses? Find target customers to work with. Those interested in your product, who have a reputation in the field or some sort of credibility, and allow their interests to be vested in your success.

By asking the world and trying to meet all those requests, you’ll lack a sound focus on your product and scope. You may end up trying to do everything instead of tackling what is important. If you have to ask what the customer wants without having anything started, how do you actually know what is important?

In the post they also say they’re beginning development within 72 hours and hope to have a prototype in a few weeks.

If you don’t know your customer, how can you begin in 72 hours? What are you going to begin? You don’t have a plan, priorities, or anything yet. And to get a prototype out in a few weeks with no game plan is unlikely.

Not to rag on anyone or anything. I wish them the best of luck, but far to often people over simply the process of building a product. Products aren’t easy. It is easy to write a program, but there is far more work to turn it into a product.