At the end of the interview, which we naturally think is worth reading in full, we talk about what the community is planning for Melody 1.1. Here is an excerpt:
CC: Are there any major upcoming enhancements or features that you are working on for the next release that you'd like to share with us?
BR: Melody 1.1 development is already in full swing. With every release we focus on improving both the core architecture of the product as well as building new features that users would find both exciting and valuable.
On the backend we are working to create a cleaner separation between our templates and the javascript that powers much of the user interface. This paves the way for us to shed the highly proprietary javascript that powered Movable Type, and in turn embrace a more robust and well supported framework like jQuery.
We are also looking to completely retool Melody's dynamic publishing engine so that designers can more easily take advantage of it when building and designing web sites.
We are also working to backport more of MT5's more popular features, like its new listing framework that provides a much richer, and more flexible way of managing content within the admin UI. It also makes it much easier for plugin developers to build their own custom listing screens and further reduces the amount of Perl one has to know in order to build a plugin.
And lastly, my company, Endevver, has spear headed a project to incubate a new design for the Melody user interface. Our desire is to release the new UI as a stand alone and optional plugin alongside Melody 1.1. This will give the new UI time to mature and stabilize, and give the community time to get used to the new design... and if they like it, hopefully fold it into the core distribution at a later date.
This marks the first time any we have talked openly about our project to offer users of Melody an alternative to Movable Type's default design. And now that the cat is out of the bag, what better time to introduce our project to the rest of the world?
]]> So what motivated Endevver to take on this project?First, there was a consensus among members of the Melody community that Melody's user interface be clearly different from Movable Type. Given our resources at the time, we were limited in how drastic of a change we could make, and thus limited ourselves to simply changing the Movable Type logo, and the default color scheme of the application. Those changes were necessary, but I don't think any of us felt they were sufficient.
Second, one thing that Endevver felt was always lacking in Movable Type's design was polish. Movable Type 4 offered a visually striking design, but as with most projects on a very tight schedule, as MT4's launch was, many of the user interface changes Six Apart wanted to make in conjunction with the new visual design were put on the back burner for a later release. These were all changes that taken by themselves were clearly "non-essential." They were changes that could never in a million years be mapped directly to a revenue opportunity, and because Movable Type's roadmap was so strongly driven by the enterprise and commercial markets, these features were perpetually sidelined. As a result, much of the polish envisioned for MT4 never happened.
Finally, our understanding of how people like to work within content management systems that support multiple web sites, like MT4, MT5, Drupal and now WordPress, has grown considerably since Movable Type 4 was initially released in 2007. We therefore wanted Melody to incorporate as much of this accumulated knowledge and experience into whatever we would build next.
In summary, we wanted to create a user interface for Melody that was not only differentiated from Movable Type visually, but also offered a more compelling user experience, one that was above all else the more polished than anything that had come before it.
A lot of attention in particular has been paid to how one navigates and moves between blogs. We wanted users to be able to move from one to another as efficiently as possible. To that end we have done a number of things:
But even with these great features, we found that scanning a text list of blog names was still not very efficient. Therefore we wanted to provide a way for users to more readily scan for a particular blog they might be looking for among a large list of blogs. What we came up with was the ability for administrators to optionally associate an icon with a blog. This icon is then used when presenting users with a list of blogs, so that they can more quickly scan for and find a particular blog.
This icon became a great way to customize a blog's appearance inside the application, so we added the option for users to also associate a color with their blog. When used together, each and every blog in Melody can thus be personalized and themed. This not only allows a blog to take on its own unique personality inside of the CMS, but it also helps cement within a user's mind the current context they might be operating within.
We are incredibly excited about this project and expect in the coming weeks to have a more formal release ready, when the first alpha builds of Melody 1.1 are made available. In the meantime, we hope the following screenshots will whet your appetite and peak your curiosity. If you want to participate in the project, then you are encouraged to join everyone at Endevver over at Melody's mailing list. We hope to see you there!
Dashboard
Dashboard w/Blog Selector Expanded
Blog Themes
]]>You can download the latest version of the Comment Subscribe plugin from our github repository.
We provided these enhancements free of charge not because we don't value our time, but because it just seemed like the right thing to do, and because it is part of our ethos of being helpful. We do this from time to time not just for our past and active clients, but for all Movable Type and Melody users. So if you are in need of some help with your content management system, drop us a line or submit a help ticket and we can help!
]]>Owned and operated by the "old media" outlet The Chicago Tribune, ChicagoNow drops traditional journalists and news reporting in favor of a large network of volunteer bloggers, all writing about the community, culture, politics, and everything else in the city of Chicago.
Investigate the network and you'll find evidence of the leading trend in the new web and mobile-based news networks: Local. The network cranks out 100 posts per day and thrives on comments and feedback from readers. Bloggers arrange in-person meet-ups at Windy City watering holes to further develop the community.
To learn more about the work Endevver did for ChicagoNow, check out our portfolio.
]]>GetSatisfaction has a stellar user interface and user experience, plus, and this is the biggest compliment we could pay any piece of software: it is fun to use. We also love how community oriented it is, which fits in nicely with our company ethos. As a result it is a product we use with a lot of our pet projects.
Tenderapp offers a decidedly very different user experience. It far more minimalistic and offers what we feel is more "professional" user experience:
In making the choice between these two services, Tenderapp has one very critical feature that GetSatisfaction does not: private tickets. You see, one of the things we at Endevver are experimenting with is how to best serve the ongoing support needs of our clients. As such, our clients are sometimes in need of sharing proprietary or private information with us, and if they can't do that safely and securely, and if we can't keep that information closely associated with their help ticket, then we are not confident we can provide the best service we can. And that's no good for anyone.
Tenderapp also integrates closely with Lighthouse - another product by entp, the folks behind Tenderapp, and another tool that Endevver practically lives in. It is the system we use to manage all bug reports to our plugins and to Melody. We honestly can't imagine our lives without this tool, and the fact that Tenderapp interfaces with it so well helps create a much more cohesive development environment for us internally. This in turn translates to a better experience for our customers because our work flow encompasses these three aspects of support seamlessly: asking for help (Tenderapp) → bug/issue/defect tracking (Lighthouse) → change control (github) [1].
So we are happy to announce help.endevver.com, a place in which we welcome all Movable Type and Melody users to ask us their questions. We will do our best to provide support to everyone when we can. Then in the coming months, based upon demand and our collective experiences using Tenderapp, we may begin exploring paid support plans to offer Movable Type users and customers.
We are very excited to help our customers and the Movable Type community in this new way and hope you will be too!
[1] I would have drawn the relationship between tenderapp, lighthouse and github as a cycle, but Illustrator keeps crashing, and Keynote and gliffy don't support circular arrows.
]]>Furthermore, the plugin helps users manage not only products to offer for sale, but also subscriptions to collect recurring payments from your customers and visitors. This opens the door for bloggers and publishers to easily offer paid-memberships to the content on their blog or web site.
(more screenshots found in our documentation)
We have worked and built subscription based products before so we know just how confusing managing an e-commerce site can be. That is why we have worked so diligently to produce as an intuitive interface as possible. Especially for subscriptions, whose policies around trial periods, billing frequencies, and subscription fees can be very confusing. Using the Store Front plugin administrators can see a human readable description of the subscription model they want to create:
The plugin also supports these many features:
The Store Front plugin is more than "just a plugin" though - it is a framework that is easily extensible by developers, allowing developers to easily develop drivers for additional payment gateways, as well as giving them the ability to integrate the Store Front plugin into existing systems like Salesforce.com, or another internal billing or CRM solution.
We at Endevver are very excited by the release of this plugin and can't wait to see what the Movable Type and Melody communities will build with it.
]]>On a recent project we wanted to help our client understand how much a move to Amazon might cost so that they could compare it to their current hosting provider. So we approached our good friend and partner Tim Appnel, the guy behind The Appnel Group, an expert and specialist in Amazon Web Services as well as having a long history as a premiere Movable Type consulting shop, to help us with some simple cost analysis. Together we architected a rather impressive footprint that has been proven to scale for the largest of organizations. The configuration involves the following resources:
Using the following configuration:
The config is simple:
I have seen installations like this power the largest Movable Type installs I have ever been privvy to, some having over 1000 blogs.
So how much would something like this cost? The largest variable for computing cost is bandwidth. This particular client has significant bandwidth requirements: 5TB in and 5TB out. It is unlikely most people will have needs such as this, so in almost all circumstances this configuration will cost less for you.
Let's break it down:
Description | Monthly |
---|---|
Compute 2 small, 2 large full-time servers instances |
$216.00 |
EBS Volumes 2 volumes, 100GB, 15 IOPS, 8 Snapshots 2 volumes, 10GB, 1 IOPS, 8 Snapshots |
$22.00 |
EBS I/O Requests 32 IOPS (2 x 15IOPS + 2 x 1IOPS) |
$8.32 |
EBS Snapshots 8 snapshots, 100GB volume 8 snapshots, 10GB volume |
$4.80 |
Elastic IPs 4 Elastic IPs (No charge if attached.), 4 Remaps |
$0.00 |
Elastic LBs 2 Elastic Load Balancers |
$36.60 |
DB Instances 2 large full-time server instances |
$633.60 |
Provisioned Storage 100GB per server |
$20.00 |
I/O Requests 259 million total requests |
$51.80 |
Backups Free to 100% of provisioned storage |
$0.00 |
Reserved Instances 1 year term on 4 listed instances |
$568.76 |
Sub-Total | $991.12 |
Bandwidth 5.6TB in, 5.1TB out, 200GB regional |
$1327.00 |
Data Processed by Elastic LBs - 5.5TB | $44.00 |
DB Bandwidth 1GB in, 10GB out, 1.3TB regional |
$14.52 |
Total | $2376.64 |
Amazon EC2 and their many other Web services can be a very logical and cost effective solution for many people. However, Amazon does not really offer any technical support services to speak of. If you don't have technical staff you can call upon, or a trusted service provider like Endevver (wink wink nudge nudge), then going with a support-oriented hosting provider like Media Temple (one of our favorites) might be best.
If you need help computing your personal costs, or would like to talk to us about moving your services to Amazon, we would be happy to chat with you.
1 Like Matt Mullenweg we believe the term "Cloud Computing" is best described as "marketing speak." In fact, from our perspective, any server that you use that you have never seen or touched firsthand is "in the cloud."
2 For this particular client, our final recommendation was to use NFS to connect the front and back ends, but the report above does not reflect the added cost of this configuration.
]]>The Asset Gallery plugin offers users the ability to embed one or more slideshows into a blog post, user profile, or page. Users have completely control over the titles and captions, as well as the ordering, for each image in a gallery or slideshow. To learn more about the plugin, visit its homepage, read its documentation, or watch the screencast!
Endevver would like to thank and invite everyone to thank the entire ChicagoNow team for agreeing to make the Asset Gallery plugin available under an open source license.
]]>Which is why Endevver is also working to provide Movable Type and Melody with a resource its users have been in desperate need of: documentation and instructions on how to build a web site using this software we love. You can find much of this documentation on Melody's web site. We have published a primer on the Melody Templating Language, and the first several introductory chapters on building web sites with Melody (a work in progress):
Our documentation will span the entire spectrum of skill levels, from beginner to expert. For experts, here is a preview of a chapter we just wrote that covers one of the more advanced topics: how to create an event calendar using Movable Type. Enjoy.
]]> Building an Event and Calendar BlogA blog can actually be a very effective mechanism by which to manage upcoming events. In this model, an event would need to exhibit the following properties:
An event must be archived according to its start date, so that a list can easily be constructed of upcoming events, or even for all of the events scheduled for a given time frame (week, month, year, etc).
An event must be automatically unpublished and removed from the web site once the event has passed. Of course some people may want certain artifacts from the event to persist even after it has elapsed; we will leave determined that up to the administrator.
To execute against this use case you will need one simple component:
Let's begin.
Once the necessary components (Custom Fields and Expire Entries) have been installed, then there is not much for you to do. They key is understanding how to manage dates properly. Remember, every event has two key dates that must be managed in a specific way for this trick to work: the start and end date/time for the event.
The event start date/time field is managed by overloading the entry's publish date. The secret is in knowing that there is nothing wrong with setting an entry's publish date to some date in the future and also having its status set to "Published" (as opposed to scheduling it to be published in the future). Once the published date/time is set, the entry will be archived accordingly. So even if the current date is actually December 15, 2009, and the publish date for an entry is set to February 21, 2010 then your blog will still publish a monthly archive for February 2010 into which your blog post will be placed.
The challenge this hack creates in one of user education. Users engaged in managing the event calendar will need to be properly briefed as to the intended usage of the "Publish On" field, because its name will not really be an accurate reflection of its behavior.
The event's end date, luckily is a little more intuitive. It is achieved by installing the Expire Entries plugin which adds another date field to the Create/Edit Entry interface: "Expire On." Just like you can schedule an entry to be published on a given date and time, this plugin provides the opposite functionality by scheduling an entry to be unpublished as a designated date and time. The Expire On field therefore is used to hold the correspond event's end date/time.
Publishing the Start and End Times for an Event
Once the managers of your event calendar have been properly changed on the proper usage of the Publish On and Expire On fields, then you need to turn your attention to what information is being published to your web site. First up: making it obvious to one of your readers when an event is scheduled to start and end. This is achieved using the date tags provided by Melody and the Expire Entires plugin, as well as a few date formatting rules.
The following recipe will output one of two start/end time formats depending upon whether or not the event starts and ends on the same day or not:
This output is achieved by comparing just the month, day and year of both the publish on and expire on fields. If they differ, then we know to use the expanded syntax.
<mt:setvarblock name="start"><$mt:EntryDate format="%x"$></mt:setvarblock>
<mt:setvarblock name="end"><$mt:EntryExpireDate format="%x"$></mt:setvarblock>
<mt:if name="start" eq="$end">
<span class="datalabel">Date:</span> <$mt:var name="start"$>,
<$mt:EntryDate format="%X"$> - <$mt:EntryExpireDate format="%X"$>
<mt:else>
<span class="datalabel">Dates:</span> Start: <$mt:var name="start"$>,
<$mt:EntryDate format="%X"$>; End: <$mt:var name="end"$>,
<$mt:EntryExpireDate format="%X"$>
</mt:if>
Displaying Events According to When They Were Added
The default sort order for an entry within a blog is according to the date it was published. However, this default behavior may not be desirable for the front door of your web site, especially if you manage a lot of events. That is because events that happen later in the year will effectively be anchored to the top of your web site. If you want to keep your readers abreast of new events being added to the system, then when they visit your homepage they may not always see what is "newest."
To fix this, you will need to change the default sort key for entries on your homepage. This is done by added one attribute to your <mt:Entries>
tag:
<mt:Entries sort_by="created_on">
<!-- your code here -->
</mt:Entries>
The above will force the events to be sorted in the order they were entered into the system irrespective of the event's start date.
You will need to remember to make this change not only to your homepage, but also your RSS/Atom feed if necessary as well.
Displaying Upcoming Events
In the event that you need to promote events that are scheduled to start soon, then you can use the days
parameter on <mt:Entries>
to display only those events scheduled to be published within a designated number of days. For example, the following template code will output all events scheduled to start in the next seven days:
<mt:Entries days="7">
<!-- your code here -->
</mt:Entries>
Summary
As you can hopefully see, managing and publishing an event calendar is not that complex and can be accomplished using some standard off the shelf components. In the next section we will delve into how you can accept events from the community for your calendar.
This tutorial is for users who have installed the Commercial.pack from Movable Type Pro into Melody as it requires the use of Community Solution. The performance of this combination has not been tested and may be in violation of your Movable Type licensing agreement. Proceed with caution.
Setting up your system to accept events submitted by readers or members of your community is slightly more involved. It still relies on the fundamentals discussed above, but a way for the user to specify a start and end date, and have those values inserted into the proper fields associated with an entry is required.
The bad news is that there is no off-the-shelf system that will do this for you. The good news is that this is a *solved problem," and that is precisely what this guide will help you in doing.
This is what you will need:
Community Solution, provided by Movable Type Pro.
Expire Entries Plugin - a plugin that will automatically unpublish entries at a scheduled date.
The courage to cut and paste and edit Perl code.
Getting Started
First of all, the bulk of the work that needs to be done is already handled for us by the Movable Type Community Solution. This piece of software has within the ability to accept blog posts submitted by the community. The missing piece is how the community is allowed to set the publish and expire on fields from the public submission web interface. Before however we get into that, let's first make sure we can setup a blog to properly accept user submissions.
Setting Up the Community Blog
The most expedient way to get started is to create a new blog and use the "Community Blog" template set in the process. This will setup all the templates for you in just a few clicks. Granted, the look and feel of this blog may not be what you desire for your own site, but it will be far easier to apply this theme and strip away all that you don't like and need, then it will be to build a theme from the ground up for you event calendar.
Once this theme is applied there will be only a few templates you will need to concern yourself with. The rest can be discarded, or better yet, customized to suit the design of your site accordingly. They are:
"Create Entry" index template - publishes the actual submission form to your web site. This will need to be customized to look like the rest of your site.
"Entry Form" template module - this is a template module that contains just the form elements for your entry submission form.
"Entry Response" system template - this template is responsible for displaying a message to the user after they submit an entry to your web site.
About the Entry Response System Template
The "Entry Response" template is the most important template in this scenario because without the system won't work. Movable Type will instead return the following error message, "System template entry_response not found in blog." The core challenge here is that this template cannot be created manually. It can only be created by applying a template set that contains a template with this ID to a blog. The template sets that contain this template for you are:
Alternatively of course, you can build your own template set and include this system template within it. The approach you choose will depend largely upon what you think will be easiest and most expedient for you.
Setting Up the Form
The best way to setup your form is to take a form generated by Movable Type and then to customize it. This is because the HTML for this form matters, a lot. You must make sure you include all of the proper hidden HTML form elements, and use the proper input names so that the data submitted is properly submitted and processed by Movable Type.
If you are using Custom Fields, then you can define all of the custom fields you want your visitors to submit along with their event, e.g. event venue, contact info, etc. The custom fields will appear and be published for you automatically if you are using the default "Entry Form" template module that comes with the Community Blog template set.
There will be several fields however that will not be published for you, which you will need to add to your form manually. They are:
The names you assign these fields will be very important because we will need to reference them in our Perl code that will populate the entry with the corresponding information. In addition, the dates and times submitted by your users must be a specific format in order for them to properly process by Movable Type. Here are some recommended names to use in the form, and the required format your visitors will need to use when supplying information to you:
start_date_d
as "YYYY-MM-DD"start_date_t
as "hh::mm::ss"start_ampm
as "am" or "pm"end_date_d
as "YYYY-MM-DD"end_date_t
as "hh::mm::ss"end_ampm
as "am" or "pm"Here is some sample HTML for the end date form elements (the start date is identical except for the form input names):
<input type="hidden" id="end_date_d" name="end_date" value="" />
<input type="hidden" id="end_date_t" name="end_time" value="00:00:00" />
<input type="text" class="date-pick" id="end_date" name="end_date" value="" size="14" />
<select name="end_hour">
<option>1</option>
<option>2</option>
<option>3</option>
<option>4</option>
<option>5</option>
<option>6</option>
<option>7</option>
<option>8</option>
<option>9</option>
<option>10</option>
<option>11</option>
<option value="0">12</option>
</select>:
<select name="end_minutes">
<option>00</option>
<option>15</option>
<option>30</option>
<option>45</option>
</select>
<select name="end_ampm">
<option>PM</option>
<option>AM</option>
</select>
Formatting Dates and Times
Asking your community members to enter in date and time according to a specific format can be onerous and error prone. Therefore it is recommended you use a third party calendar library with a little custom javascript to assist users in this process. This example utilizes jQuery, the jQuery date plugin and the jQuery Date Picker plugin to make this happen. Once installed, here is the javascript you will need to add to your Create Entry template to properly reference these javascript libraries:
<script type="text/javascript" src="<mt:StaticWebPath>plugins/MyPlugin/js/jquery-1.3.2.min.js"></script>
<script type="text/javascript" src="<mt:StaticWebPath>plugins/MyPlugin/js/date.js"></script>
<script type="text/javascript" src="<mt:StaticWebPath>plugins/MyPlugin/js/jquery.datePicker.min-2.1.2.js"></script>
Then this javascript can be added to the same template so to properly initialize your calendar widgets and date fields:
Date.format = 'mm/dd/yyyy';
$(document).ready( function() {
var today = new Date();
$('.date-pick').datePicker().val(today.asString()).trigger('change');
$('#start_date_d').val( today.asString('yyyy-mm-dd') );
$('#end_date_d').val( today.asString('yyyy-mm-dd') );
$('#start_date').bind(
'dpClosed',
function(e, selectedDates) {
var d = selectedDates[0];
if (d) {
d = new Date(d);
$('#start_date_d').val( d.asString('yyyy-mm-dd') );
}
}
);
$('#end_date').bind(
'dpClosed',
function(e, selectedDates) {
var d = selectedDates[0];
if (d) {
d = new Date(d);
$('#end_date_d').val( d.asString('yyyy-mm-dd') );
}
}
);
});
We are getting closer. Hopefully though we have not lost you along the way as the above recipes all require some familiarity with Javascript. If you need help along the way the Melody and jQuery communities are both very helpful resources to call upon for help.
The Movable Type Plugin, a.k.a. "Perl Code"
If you have gotten this far, it will assumed that you have successfully gotten your event submission form working. It may not set the publish on and expire on fields properly, but you will have:
If you have successfully performed the three tasks above, then the rest is really just a bunch of copy and pasting - with perhaps a tweak here and there.
Every Melody plugin first requires you to create a config.yaml
file. Let create it in the following location:
$MELODY_HOME/plugins/DatePopulator/config.yaml
In this file let's put the following contents:
name: Date Populator
callbacks:
MT::Entry::pre_save: $DatePopulator::DatePopulator::entry_presave
MT::Entry::post_save: $DatePopulator::DatePopulator::entry_postsave
This config.yaml
file refers to two subroutines that you must implement (again, by a little copy and paste). These subroutines will live in a perl file you are about to create. Now, create the following file:
$MELODY_HOME/plugins/DatePopulator/lib/DatePopulator.pm
In this file, paste the following:
package DatePopulator;
use strict;
use Carp qw( croak );
# You can edit the values below if you have customized the
# field names in your HTML
use constant FIELD_START_DATE => "start_date_d";
use constant FIELD_START_TIME => "start_date_t";
use constant FIELD_START_TOD => "start_ampm";
use constant FIELD_END_DATE => "end_date_d";
use constant FIELD_END_TIME => "end_date_t";
use constant FIELD_END_TOD => "end_ampm";
sub entry_presave {
my ( $cb, $obj ) = @_;
my $app = MT::App->instance;
if ( $app && ($app->isa('MT::App::CMS') ||
$app->isa('MT::App::Community'))
&& $app->mode eq "post" ) {
my $q = $app->{query};
my $d = $q->param( FIELD_END_DATE );
my $t = $q->param( FIELD_END_TIME );
$d = "$3-$1-$2" if ($d =~ m!^(\d{1,2})/(\d{1,2})/(\d{4})$!);
my $end_hour = $q->param(FIELD_START_TOD) eq "PM" ?
$q->param('end_hour') + 12 : $q->param('end_hour');
$end_hour = $end_hour < 10 ? '0' . $end_hour : $end_hour;
my $end_time = $end_hour . ':' .
$app->param('end_minutes') . ":00";
$app->param('expire_on_date',$d);
$app->param('expire_on_time',$end_time);
require ExpiredEntries::Plugin;
return ExpiredEntries::Plugin::pre_save($cb, $app, $obj);
}
return 1;
}
sub entry_postsave {
my ( $cb, $obj ) = @_;
my $app = MT::App->instance;
return 1 unless ($app->isa('MT::App::CMS') ||
$app->isa('MT::App::Community'));
if ( $app->mode eq "post" ) {
my $q = $app->{query};
my $d = $q->param( FIELD_START_DATE );
my $t = $q->param( FIELD_START_TIME );
# This should never happen
$d = "$3-$1-$2" if ($d =~ m!^(\d{1,2})/(\d{1,2})/(\d{4})$!);
my $start_hour = $q->param( FIELD_START_TOD ) eq "PM" ?
$q->param('start_hour') + 12 : $q->param('start_hour');
$start_hour = $start_hour < 10 ?
'0' . $start_hour : $start_hour;
my $start_time = $start_hour . ':' .
$q->param('start_minutes') . ":00";
$obj->authored_on($d . " " . $start_time);
$obj->save();
}
return 1;
}
1; # Don't forget this line!
If all goes well, then you will have successful closed the loop and now possess a theme that will allow community members to submit calendar events to your system.
]]>If you have a panel about open source, blogging, Movable Type or Melody, let us know so that we can vote for it as well!
]]>In short Image Cropper addresses the problem web site producers have in creating and crafting the images they use on their web site to promote their content. Image Cropper enables producers to create a set of standard image sizes, crops and filters directly within Movable Type and Melody where they can be automatically applied when authors create their entries. This completely eliminates nearly all of the post-processing steps normally performed by complex tools like Photoshop.
Not only does this save time and money, but it helps every blogger produce a web site that looks as professional as those who commissioned and sponsored the development of this plugin: Talking Points Memo (an Endevver client). Check out the demo:
But Image Cropper is a tool not just for producers, it is a tool for designers as well. Similar to the suite of plugins we maintain and support, like Config Assistant, Custom CSS, Custom Header and more, Image Cropper exposes a simple config file-driven mechanism for theme designers to create and specify their own custom image sizes that Image Cropper can help users of the theme to produce.
Our ultimate goal here is to make Movable Type and Melody easier and more fun to use, but also to make it a tool that designers like to use because it helps them produce great products faster and cheaper.
To learn more, visit the Image Cropper homepage, which contains links to our documentation and our bug tracking system.
]]>Through all of this, I have enjoyed an incredible amount of success, built up an excellent client base and have collected a wonderful team of talented partners who make the Endevver engine run. The only real challenge I have had is my ability to meet the great demand that exists for Endevver's services.
Given that I work with many other firms and independent contractors alike to produce our client's cutting edge and beautiful sites, I certainly could just increase capacity by farming work out. However, I have always felt that it was absolutely critical that I be intimately involved with each project (usually as the primary developer and/or project manager) to ensure that my extremely high quality standards would always be met.
The end result is: There's never enough of me to go around.
Luckily, I've found another who shares my passion for quality, who matches my level of expertise, with whom I've already worked alongside for years and who brings to the table qualities I do not posses that complement my own. For all of these reasons, I am happy to announce that Byrne Reese has joined forces with me as a full partner in Endevver Consulting.
Byrne and I have long been friends, but what brought us together as partners was the realization that we could accomplish and help our clients accomplish so much more by working together, than we ever could working on our own. What makes that possible is simple: unparalleled expertise.
Together, we possess over thirteen years of experience using, working with and developing for Movable Type and, in fact, have defined its direction and daily progress for much of the past 4+ years. We have contributed numerous features to the core product and together we have released well over forty open source plugins and themes for the platform. Through all of this, we arguably possess, as a team, the greatest and deepest knowledge of Movable Type in the industry, outside of Six Apart.
What this means for our clients is simple:
More Services - With an even greater array of experience on board, we can begin delivering a wider variety of services to the Movable Type community.
Faster Time to Market - With more people working for you, we will be able to bring your products and web sites to market faster.
Greater Capacity - By expanding the Endevver team, we make it possible to service more clients across a greater spectrum of needs.
Our work together has already culminated in a project we are immensely proud of: Melody.
We conceived of Melody in our initial conversations about working together. We decided it was something we should do not just because we love Movable Type and want to see it flourish, but because as professionals Melody presents the opportunity to us to provide a better and higher quality product to our customers. It also allows us to more easily deliver solutions more tightly tailored to meet our client's needs.
To make it happen, we quickly pulled together a dream team of many of the very same people that we work with as Endevver partners in our everyday client work as well as a few more who are leaders in the MT community and beyond. The results, we believe, speak for themselves.
We'll certainly talk more about Melody in the coming days, but I wanted to say now that Byrne and I are excited to make Endevver one of the first companies to officially offer support and services for both Melody and Movable Type. We are also incredibly proud to be a part of Melody community, as co-founders, as board members of the Open Melody Software Group and, most importantly, as contributors to an effort that we believe strongly will be a success.
The only thing remaining is this simple question, "what do you want to build today?"
Endevver can help.
]]>