Tag Archives: software

SpiralKit

Introducing SpiralKit

A little more than a year ago, I released my first iPhone application, Spiral by Digital Generalists.  After several updates and many happy customers, I’ve decided to release the drawing engine for Spiral as an open source framework through my company, Digital Generalists, LLC..

What Is SpiralKit

SpiralKit is a Quartz 2D-based drawing framework for iOS written in Objective-C. The framework enables ‘drawing’ on a UIView in an iOS application and ships with pen, highlighter, and eraser drawing effects.

The framework is built specifically to enable easily adding new effects, color spaces, and drawing algorithms in a modular fashion. If you want to provide a unique drawing effect, support of the CMYK color space, or a custom drawing algorithm, you can add such features to SpiralKit without having to modify the fundamental components of the framework.

Where to Find It

The project is hosted on GitHub at https://github.com/digital-generalists/spiralkit.

More Information

See the release post on the Digital Generalists site and the framework documentation for all information about using SpiralKit in your application.

Blueprints

Evaluating a Proposed Application Architecture

At work, I’ve recently had a few conversations about the best way to evaluate candidate architectures for a software project, so I decided to put down a few ideas I have on the topic.

Project Intake

Firstly, there are several questions that need to be answered and understood by all stakeholders of a project before you can properly evaluate an architecture:

  • What are you planning to build?
  • Why are you building it?
  • Who are you building it for (i.e. who is your audience)?
  • How will success be measured?

At a technical level, most projects start with an answer to the first question and have a weak or vague understanding of the other three. However, if you can’t answer those three questions, you don’t have a good justification for the answer to the first one.

The first task is to get agreement on the answers to Questions 2 through 4 and verify the answer to Question 1 still fits. If it doesn’t, use the opportunity to identify what can be built that fits the needs of the answers to Questions 2, 3, and 4.

Business Environment Analysis

Most technical ecosystems have processes and expected technical standards that apply to all applications within the ecosystem. Your organization does things a certain way.  Your team likely has expertise in a specific technology.  Your business also likely has requirements around protecting the environment and facilitating support of the application.  These factors should be identified:

  • How are applications expected to authenticate and authorize users?
  • Are there standards around data security?
  • Are there standards around data retention?
  • Are there standards around transport protocols?
  • Are there expectations around supported platforms?
  • Are there standards around accessibility?
  • Are there standards around logging?
  • Are there standards around analytics?
  • Are there expectations or standards around interoperability across applications?
  • Are there standards regarding UI conventions?
  • Will the new product provide technical challenges to existing distribution and delivery models?
  • Will the new product provide technical challenges to existing support mechanisms?
  • Are there standards around code documentation?
  • Will the new product provide technical challenges to existing documentation procedures?

The answers to these questions will identify many of the inherent technical requirements of the system. These aspects are related to the notion of certifying the application as “good and complete” as your organization defines that term, even if informally.  If there is no formal certification process, either within your company or externally, for the application, answering these questions will help define what “good and complete” means to your product.

Technical Environment Analysis

The next step is to identify what you already have in place and how the new product will fit into the overall ecosystem.  Few applications are 100% greenfield with zero dependency on existing systems, so it is paramount to understand what environment you will be working with.

  • What systems are already in place?
  • What role will those existing systems play in the new product?
  • How will the new system affect seemingly unrelated products?
  • What types of access privileges are required to interact with these systems?
  • What integration facilities already exist in the identified systems?
  • What data does the new application need and where can it pull that data from?
  • In what formats are the data accessible?
  • What second-level dependencies exist?

Technical Architecture Review

At this point, we should have enough information to apply a proper architecture review. Firstly, you verify the proposed architecture addresses all of the concerns identified in the Business and Technical Environment analyses.

After those business-related concerns are addressed, most of the remaining aspects of the architecture will be technically focused.  However, technical concerns tend to be highly domain and context specific.  The meaning of “good and complete” when it comes to these technical concerns will be influenced by the programming language, platform, organization, and product. In general though, the following concerns tend to apply regardless of context and can be used as a base set of technical concerns to review regardless of project:

  • Separation of Concerns: Each component of the system should only do one thing and do it well. In practice, this minimally means ensuring a strong separation between the business logic implementation and the UI.
  • Abstract Interfaces: Are the touch points between the system integration points and product components done in a way that effectively hides implementation details of both sides of the integration?
  • Scalability: Can the proposed implementation easily scale to accommodate concurrent execution of the same logic processes across different data sets?
  • Maintainability: Is the architecture well reasoned, consistent, and easily modified?

When Should Architecture Reviews Occur?

You do not want an architectural review to impede the development process. Your goal is not to create the “perfect” architecture.  Your goal is to build a solid product.  However, you want to identify issues with a proposed architecture early enough to do something about any problems an architecture may have.

  • Ideally, a review of a proposed product architecture should occur before any coding has begun. (This is nearly impossible to achieve in my experience.)
  • A more realistic ideal is that a full architecture review should be conducted as soon as a potential product’s prototype or alpha implementation is minimally functional.
  • At a minimum, a full architecture review must be conducted as soon as a proposed product reaches the release candidate stage if one has not been completed earlier.
  • A full review should be conducted once prior to the product’s initial release. As soon as this occurs, summary reviews of the architecture will likely be sufficient at subsequent steps of development and maintenance.
  • For ongoing development, a summary architecture review should occur at the start of each new release and again as part of the project’s release criteria (ideally at the end of the last development sprint) or as soon as the first release candidate is identified.

A Reality of New Product Development

Most new products/applications start out as skunkworks projects. Typically an individual or a small group builds a product prototype and uses that prototype to gain approval/funding for the project.  As a consequence,  a new product often starts life with a sizable, un-vetted code base and significant technical debt. The process for bringing these products to production involves:

  • Conducting a full architecture review.
  • Documenting gaps in all of the aspects identified above.
  • Conducting a full code review.
  • Identifying all technical debt as issues/defects in your project tracking system.
  • Prioritizing architectural gaps and identifying gating issues.
  • Creating a plan to address all non-gating issues in a timely manner.
  • Verifying that all gating issues are addressed before the product is released to production.

The process I’ve laid out is intentionally light on specific procedural details because each organization is different and each technology stack and platform carry specific technical concerns.  The mechanics of a formal architecture review process need to be crafted based on the specific needs of your organization and the technology you are using.

However, this outline should provide a good abstract notion of what goes into an architecture review.  The items and concerns I’ve outlined probably aren’t comprehensive.  If you feel I’ve overlooked something important, please mention it in the comments.

Spiral by Digital Generalists Application Icon

An App of My Own

After releasing several mobile applications for the companies I’ve worked for over the last couple of years, I finally released an iPhone application of my own to the App Store, Spiral by Digital Generalists. See the launch post on my company’s website for all of the details about the app.

Spiral by Digital Generalists

Spiral is the perfect application for lovers of pocket-sized paper notepads who want to take quick notes, draw, sketch, doodle, and more! All these things can be done by simply “drawing” on the application with your finger or a stylus.

Spiral uses a world-class drawing engine that provides smooth lines and a fluid writing experience. We worked very hard to make using Spiral feel like writing on an actual notepad, and we’re proud of what we built.

Designed specifically for the smaller size of the iPhone, Spiral gives the power and features of notepad applications available only on the iPad in a way that works well on a smaller screen.

 

Give Spiral a try today!

Download on the App Store
Markers

Marker Interfaces

Marker interfaces tend to be one of those things that your don’t think about often.  But when you have a problem they can help you solve, you think they are awesome.  The trick is knowing when they should and should not be used.

What is a Marker Interface?

Marker interfaces are basically an interface contract with no methods or properties specified.  The notion of interface contracts are common in many languages but take on many different names.  If you’re familiar with Java interfaces, Objective-C protocols, C++ pure abstract classes, or any similar technique in your language of choice, you know what I’m referring to.

Typically, an interface contract specifies a set of methods that must be implemented by any object that intends to support the contract.  This enables you to refer to an object by the contract (which typically corresponds to a functional role or feature role in the program) rather than the concrete type of the object itself.  This both clarifies how code consuming an object intends to use the object and makes it possible to easily use different concrete classes that also implement the contract without needing to change the consuming code.  The consumer doesn’t care about the concrete object type as long as it satisfies the contract.

So why on Earth would you ever want to create a contract that doesn’t specify any methods?  Most of the time, you don’t. But if you need a way to abstractly specify an object type, especially when the abstract type may have concrete instances that don’t share a meaningful inheritance chain, then marker interfaces are likely a perfect solution.  You most often have a need to specify an abstract object type like this when you have orchestration or coordination code that is transferring objects from one part of a program to another.  The orchestration code doesn’t need to use or modify the object, it just needs to move it from one place to another.

Such orchestration code tends to be both fairly abstract and highly leveraged within an application’s architecture, so you often don’t want to specify concrete types for the objects being sent back and forth.  A simple way of generically passing objects is to specify the parameters of methods in the orchestration code as generic objects.  But specifying transfer method parameters as a generic object has a few downsides.  Firstly, it doesn’t provide any guidance to the caller about what should be passed.  Secondly, literally anything can be passed.  If you accidentally pass an object you didn’t intend to, the compiler/parser won’t catch the error.

void transfer(Object data)

Marker interfaces help avoid these problems.

By using a marker interface, you can specify the intent of what should be provided to the method without restricting you to a specific type or inheritance chain.

void transfer(IFooDataObject data)

This method signature is much clearer to the person using the method what type (in the functional intent sense of the word) of object should be passed to the method.  Any concrete type can still be passed, but you have to make a conscious choice about which objects should be allowed to be passed by adding the marker interface to the type definition of the object before you can pass an object of that type. In a mature architecture, prior decisions about which objects carry this declaration can greatly minimize confusion about what to send where.

You also get a level of type checking via the compiler, so if you accidentally pass a reference to a UI control object instead of the data property on the control you intended to pass, the compiler can let you know.  Without the marker, it wouldn’t.

This technique of using marker interfaces for high-level type specification is really the one application of marker interfaces I use frequently.  I tend to not like using marker interfaces to direct flow of control within an application (i.e. “if foo implements bar then do x”) because I think such control flow is typically better governed by object state than by type. But that thought is probably worth a post of it’s own.

How to Convert a String Representing a Unicode Character Sequence to the Unicode Character

I recently received some translated resource files from the Translations team at work.  To my surprise, all of the files, even those for double-byte languages, were returned in ASCII encoded files.  After some inquiry, I found out that because of the technical limitations of a proven legacy system, all translation files were encoded as ASCII.  What this meant is that I was confronted with a set of ASCII text files containing Unicode escape sequences (\uxxxx) that I was responsible for converting to a proper Unicode encoding.

While solving the problem, I came across a couple solutions for converting Unicode escape sequences to a different encoding.  The first was to use the StringEscapeUtils class in Apache Commons Lang.

String lineOfUnicodeText = StringEscapeUtils.unescapeJava(lineOfASCIIText);

Using the StringEscapeUtils class is very straightforward; simply read the contents of the the ASCII file line-by-line, feed the line of data in to the unescapeJava method, and write the unescaped text to a properly-encoded new file.  But this technique requires writing a utility program to feed the contents of the ASCII files into the StringEscapeUtils methods and then write the transformed string to a new file.  Not hard to do, but much more work than ideal.

The second solution is to use the native2ascii utility included with the Java JDK.  The utility can take the input file and perform effectively the same unescape transformation that Apache Commons does.

native2ascii -encoding utf8 c:\source.txt c:\output.txt

A very simple solution that works as advertised.  No quirks or caveats that I’ve noticed.  There’s even an ANT task for incorporating native2ascii into build scripts.

Extension Cords

The Power and the Pain of Plugin Development, Part 3

Previously, we looked at why a client-side plugin architecture might be a good idea and why it might not be.  Now, let’s formalize our recommendations.

Some Final Thoughts on When You Should and Shouldn’t

Now that we’ve discussed some of the benefits and pitfalls of taking on plugin development, hopefully you have a better feel for when leveraging a plugin is appropriate for your project. However, there is an additional aspect that I factor into my evaluation:

  • perceived appropriateness for the platform

Basically, this factor is meant to gauge both how frustrated your users will find the idea of a plugin and how friendly the general developer community is to the idea of plugins for the platform category to which your host application is perceived to belong.

This is how I break down platform categories as they apply to this particular question:

  • desktop software built on the idea of plugins
  • desktop software that has a plugin API, but isn’t plugin-oriented at it’s core
  • web browsers

Desktop and Based on Plugin as the Core

Software of this variety tends to be complicated, valuable, and used for sophisticated work. The most well known examples are Adobe Creative Suite and Eclipse. Less prominent members of this class are smaller, albeit popular, applications such as Emacs and command shells on various platforms. The products are built in such a way that core product development is often done as plugins. In these ecosystems, plugins are not just encouraged, they are expected.

For disciplines such as media design and software programming, these nuanced products tend to have highly technical users asking for a solution to very specific problems. In environments such as this, plugins tend to flourish. If this is where you’re project is targeting, you should have few concerns about the appropriateness of using a plugin as the delivery channel.

Desktop with an API but without Primary Orientation

This is, more often than not, the Microsoft Office case. While there are other products that fit this category, Office is the prominent player. Typically, there is a very polished extension API and even a large and committed community around extending the products. But unlike the more technically-oriented applications mentioned above, the technical fluency of this class of software’s users can vary widely.

Plugins can be successful and popular here. The appeal of having software do new and cool things is a universal draw. You don’t have to be a geek to love a new feature.

However, because the broader audience tends to be less tech-savvy, UI, delivery, and support decisions typically need to be more conservative. In general, you want to make sure your design and marketing message are closely aligned with the attitudes of the people likely to install the plugin.

Because the user of these applications tends to be less technically-oriented, the place of plugins in the ecosystem tends to take more of a secondary role. Your plugin would need to become phenomenally popular to give it comparable clout with the internal Strategy and Architecture teams at the host application. On these platforms, you must be prepared, and frankly expect, to rewrite the plugin often and abruptly in these ecosystems.

Web Browsers

Early in my career, I tended to think of web browsers in the same class as the “Desktop with an API but Nothing More” camp. The browser was an extremely widely-used desktop application with a good extension API. However, over the course of time, I’ve significantly revised that assessment. Browsers are in a class of their own.

Because browsers tend to lag only operating systems in terms of usage, browser plugins come up very often on product roadmap wish lists. However, the size of the audience is almost always more of a curse than a blessing.

One of the most resonant messages uttered by advocates of the “pure web” movement has been that things on the web should be free and that they should be universally available. I have been shocked often at how articulately non-technical users can attack any bit of software that doesn’t fit the free and universally available model of the pure-browser-delivered web. Even if your plugin is free, it will run afoul of the “universally available” purists if it doesn’t seamlessly run on every platform without any user interation.  Just ask Adobe.

Personally, I think this frustration often boils down to the fact that most people don’t care about technology, only the things technology can do for them. So any point of view that affirms those two notions is innately appealing.

Because of that, most of that uber huge audience of browser users tends to be:

  • annoyed that they should have to install anything for any !@@#-ing reason
  • skeptical that anything they are asked to download and install is actually free or safe

Installing software can be a pain, especially on a system like Windows that often insists the user close an application or reboot the machine to complete an install. Users expect access to a site’s information or functionality to be available as soon as the page loads.  Anything that gets in the way of that is an annoyance, plugins especially.

In general, I’ve found web browsers are an unforgiving platform for plugin development. Expectations for cross-browser support and the ability to override or circumvent security mechanisms tend to run pretty high. Because the zero-friction, potentially cross-platform delivery channel of HTML is available literally right in the same application, the question of ‘why aren’t we doing this as a web application?” essentially never goes away with web browser plugins. Because of this, in my opinion, browser plugins should be avoided.

Conclusion

That’s my take on plugin development.  Hopefully the information will help you in determining whether a plugin is the right choice for a software project.  Like I said above, this series is based on my experiences in building plugins and not intended as gospel truth.  Like all things in software, your mileage may vary.

Extension Cords

The Power and the Pain of Plugin Development, Part 2

Last week, we looked at why you might consider plugins.  Now let’s look at why you might not.

This Sounds Awesome! Why isn’t Everything a Plugin?

Although plugins are powerful, can save you time, and can help in user adoption, they are not free of drawbacks that must be considered.

A quick list of potential pitfalls that you should consider when developing a plugin are:

  • technical restrictions placed on plugins by the host application
  • how to play nicely within a UI you don’t fully own
  • licensing requirements that may be imposed on your plugin
  • how hard will it be to find and install the plugin
  • where does “help desk”-style support for your plugin end and for the host application begin
  • Lashing yourself to a “narrow” platform

This is far from an exhaustive list, but covers most of the challenges I’ve encountered. Your circumstances likely will govern just how complete this list feels.

Technical Restrictions

It’s tempting to believe that because plugins are typically written in “native” code that developing a plugin will provide the same degree of freedom that developing a stand-alone application does. More often than not, this isn’t the case. Even if the host application allows your plugin to execute in an effectively unrestricted manner, your ability to control and interact with the host application in a sanctioned way is still constrained by the host’s plugin API.

Even more importantly, just because you technically can do something, doesn’t mean that you should do it. Your plugin is a guest in someone else’s house, so it is typically a good idea to act on your best behavior. A healthy amount of respect for the plugin’s operating environment will go a long way toward preventing future maintenance and compatibility headaches as your plugin and the host application grow old together.

How to Play Nicely in a UI You Don’t Fully Own

Continuing with the notion of respect for the operating environment, more often than not, a plugin should visually and functionally fit within the host application. The visual appearance of menus, dialogs, buttons, etc… should all take their queues from the host application. The same thing applies to more functional notions such as the concepts of navigation and initiating actions. If the host application tends to use buttons to initiate an action, then the plugin most likely shouldn’t use text links as the primary mechanism for initiating actions.

Like most things of a design nature, this particular advice is a bit subjective. If you have a good thought on differentiation through the look and feel of the UI, have a thorough appreciation for how a drastically different appearance may be perceived by the end user, and you still feel strongly that you should implement a custom look for your plugin, then the last thing I want to do is advise you not to do so. Just go into such decisions with honest conviction. If you are on-the-fence or ambivalent at all about making that kind of design decision, you probably shouldn’t. If you’re confident you understand what you’re doing and that it’s the right thing to do, then with all sincerity, Godspeed.

A related aspect to general look and feel is that the UI shouldn’t strive to dominate the host application. In my experience, a Development team usually looks at this position as “not a big deal.” However, once you involve teams like Strategy and Marketing, their first impulse likely will be to make their product as apparent and prominent as possible.

It is a natural impulse and, realistically, the “right” position for those teams to take, but it’s also a move almost guaranteed to backfire if you are too aggressive about it while running within the context of another application. I assure you, that if a user installs your plugin and then sees it within the host application as a 600px wide sidebar that they cannot resize and are presented with a nagging dialog asking essentially “why no love?” when the user tries to close said sidebar, your user (also known as the customer) will hate you. They may leave that sidebar open forever. They may even use it’s unbelievably awesome feature from time to time. But she or he will always hate you. And they will never voluntarily do anything for you again.

The essence of this guideline is that by agreeing to be part of a larger application, you are implicitly seeding some degree of design control to the host application. If you think Outlook is a usability disaster and a primary element of the value proposition of your plugin is world-class user experience, then you may want to rethink whether an Outlook plugin is the right delivery channel for your application.

Licensing Requirements and Impositions

A review of source code licensing will likely take a big role in the later stages of your project. It will likely manifest as a big checklist from the legal department asking what open source projects have been used; for copies of every third-party header included in the project; for assurance that the proper license disclosure is in all source files, etc… The need to cross ‘t’s and dot ‘i’s regarding how source is licensed and used is a big concern of any company of reasonable size.

And if you’re delivering a plugin, the chances are really good that you’re going to have additional questions to answer than you would if you were delivering a stand-alone product. At a minimum, you should be familiar with any licensing requirements imposed by use of the host application’s plugin SDK and get sign off on its use from your company’s legal team and senior management before you start the project. I’m not a lawyer, so don’t treat this as legal advice because it’s not, nor does it intend or claim to be in any way. But you still should.

How Hard Will It Be to Find and Install the Plugin

This one usually isn’t a deal breaker for plugin projects and is generally a common concern for any software product, but people tend to overlook this regarding plugins until late in the development cycle for some reason. When designing the product, think through how a user will both find the plugin and how they will install it.

If the host application has a site or integrated install/update feature that the user can search to find the plugin, then that’s a good sign. Figure out what you need to do to be placed prominently in that ecosystem. If the user can install the plugin directly from the host application without requiring a restart of the application, regardless of where they get it, even better.

If the user has to go to your company’s website, download a TAR file, go to a different website to download WinRAR just to unpack the TAR, unpack it, run a command script with admin privileges, and then reboot the computer, all just to install your plugin, then you’ll likely face some adoption issues regardless of who your target user is.

What Does Support Mean for Your Plugin

Regardless of how clearly branded your plugin is and how distinct the host application makes plugin UI from the base UI, to an end user, your plugin is part of the host application and the end user typically has no notion of where the host application’s bits end and your plugin’s bits begin.

While this can be a goal to aspire to regarding the user experience, it can lead to headaches for your support organization. Your team will need to think through what is and isn’t a question that your support organization should field. Realistically, you should also prepare resources that can be referenced, even informally, so that Support can at least steer people in the proper direction if it’s appropriate to do so.

Additionally, your plugin becomes colored by the perceived stability of the host application. If the host application crashes all of the time, especially if your plugin looks like it’s doing something when the host does crash, your plugin becomes a candidate for blame whether it was actually at fault or not. There’s little you can do to categorically prevent this beyond ensuring high quality in your plugin and possible messaging on a social media channel. You’ll need a thick skin and fully invested management to weather a plugin quality critique whether or not your plugin is the root cause of the problem. I strongly encourage ensuring you have both before setting a plugin loose into the wild.

Lashing Yourself to a “Narrow” Platform

This particular constraint can be an interesting one and related push back is typically fueled by the background and general work outlook of the organization. Many developers loath the idea of building for a single platform. Most companies do as well, albeit often for different reasons.

While the vast majority of widely-used software has established some notion of multi-platform support, two of the most widely targeted plugin platforms, Internet Explorer and Outlook, historically have been decisively single-platform, and in IE’s case, still so in a largely concrete way.

You must make sure that you have a good answer to the question of multi-platform support. If the majority of your customers are on a single platform, then targeting the plugin for that platform while providing comparable functionality in a less-targeted manner for your secondary platforms will likely be not just regarded as a good solution, but a great one. But you need to think through how that will look early in design.

Next week, we’ll look at some special considerations regarding plugin development and formalize recommendations for when you should and shouldn’t use plugins.

 

Extension Cords

The Power and the Pain of Plugin Development

Call me strange, but I really enjoy client-centric plugin development. I think plugins are a powerful extension model for large software products, especial those of the pre-packaged, commercial-off-the-shelf variety such as MS Office. In a geek sense, plugins are awesome.  However, over the years, I’ve grown skeptical of projects where the assumed solution is a plugin, or extension or add-on if you prefer.

Plugins can be great, but they’re not right for every situation. I start the product design phase by assuming that a plugin is probably not the right option for the project and plan to implement a plugin only after I’m satisfied it’s the best, and often only, solution for the problem the project is aiming to solve.

Let’s Agree on What We’re Talking About

Before examining what I feel are the pros and cons of plugins, let’s have a brief discussion on terminology. I find the nuances between the categories of plugin, extension, and add-on tend to be highly technology/platform specific while the functional difference between them is more or less insignificant. So I’m choosing to use the term plugin generally to refer to:

a packaged software component that conforms to the public API of a host program, is intended to augment the functionality of the host program, and appears to the end user to be a seamlessly-integrated part of the host program

Additionally, I want to acknowledge that plugin architectures exist for server-side products, and that those solutions share many of the attributes of their client cousins. If anything, server-side plugin development has significantly greater productivity gains because you can eliminate the end-user “technical familiarity” limitations associated with leveraging them. However, this article takes a client-focused perspective.

The Value of Plugins

With that out of the way, let’s continue with what makes plugins great and when you should use them. In my mind, the primary benefits of plugins boil down to these two things:

  • user familiarity with a product
  • integration into a larger functional process flow

User Familiarity with a Product

Building an intuitive application that is easy for anyone to use is hard. Very hard. Whole disciplines have emerged over the last few years where practitioners devote themselves solely to the study and understanding of design-focused topics like user experience and practical implementation techniques such as user-centered design. If you believe your passion as a developer and the raw, untapped value of your application are enough to get people to use it, you’re probably wrong.

Because building an inherently “usable” system is difficult to do, simply encouraging people to engage with your new application can be a challenge. If there is a business-oriented expectation that a new user will need to learn how to use a new product, that product better deliver tremendous value that the user can’t get elsewhere, otherwise that user simply won’t bother investing the time to become fluent with your product.

Plugins can help overcome some of the challenges associated with user adoption by exposing the new functionality as part of an application the user is already familiar with. If a user already knows how to use Outlook and already opens it first thing in the morning, you can gain a tremendous leg up in encouraging user adoption by making your application a part of Outlook.

Integration into a Larger Functional Process Flow

What I mean by integration into a larger functional process flow is that not every feature or function deserves its own application. Some features, even powerful and valuable ones, only make sense in the context of broader functionality.

If your project is intended to provide a mechanism for generating rich graphs and charts from data stored in your CRM system, it doesn’t really make sense to write an entire word processor just to satisfy the “must be easy and intuitive to embed into text documents” requirement. A plugin for Word will likely be a better option for such a requirement.

A more nuanced but less clear-cut example of when this guideline is applicable would be this: if you are developing a programming language, should you write your own IDE or adopt Eclipse with your language supported as a plugin as your development environment?  It’s a complicated question with many non-technical influencing factors.

In practice, I’ve found that evaluating projects on this scale tends to feel less like the glaringly obvious first example and closer to the more nuanced second, where there are likely compelling reasons from the business and product strategy points-of-view to invest in re-implementing functionality that may offset the technical benefit of piggy-backing off of an existing application.  Even when a plugin may be the right technical fit, it may not make sense from a business perspective.

But even in those less-obvious scenarios, engaging in the exercise of thinking through how a new feature could be incorporated into a tool the user already has and loves is a valuable exercise. Intelligently leveraging the work of others is a practical reality in professional software development, so you should at least talk through the possibilities plugin architectures present.

Next week, we’ll look at the reasons why you may want to avoid a plugin architecture and implementation.