Had an amazing time at Social Dev Camp 2011 this past weekend. For those of you who don’t know what it is, it’s self-described as “Summer Camp for the Social Web”. It included talks about a variety of development and business topics, an “unconference” (sadly I didn’t make it to that), and a hackathon.
Of course, the best part was networking with excited professionals in this space, so HUGE shout-out to everyone I met over the weekend! Thanks as well to all the volunteers who made it possible.
As is normal with conferences, some of the talks were a bit too broad or too oddly specific. The “Heedful Programming” guy talked a lot about the agile/pair programming stuff that I don’t drink the kool-aid on quite as much anymore, but that’s a topic for another day. I really enjoyed David Kadavy’s “Design for Hackers”, though, since I end up spending a lot of time in that space.
I do have to say the choice of keynotes was perfect as they were my two favorite talks. Julien Smith’s “Visibility is Power” and Alexis Ohanians “Build Big Little Communities” both had strong messages about how to get a product or service noticed. Basically, do NOT think that buying a few google ads is going to cut it.
I went to the hackathon with a couple friends of mine who work for the University of Michigan – Scott Goci and Michele Wong. There was a “Hackathon” alongside the conference, and we decided to enter as a team. The rules were fairly simple – teams had to create an application that was in some way “social” (hard NOT to do), and they had 36 hours to do it. As in 36 hours total, including time we would otherwise be using for sleeping.
At the end of the 36 hours, we presented “Tweap” to giant auditorium. Our idea (which Scott came up with) was simple – Twitter often has a lot of companies and users tweeting about coupons and promotions, so why not simplify that process? We made a web application (tweap.net) as well as an iPhone app that i’ll polish and launch soon. It’s simple, and entirely a fun side project, so we’re not planning on monetizing it or anything.

In any case, people loved our idea and we came away with with top prize, “Best Overall”! Huge thanks to Min and Lwin Maung, last years winners, for giving us tips on the presentation. Hopefully the video of our presentation will be up soon.
I won’t presume to actually give people advice on how to win hackathons (the criteria was fairly ambiguous). Our strategy was in many ways one of “Ambition is the enemy of success”. We aimed for a very simple but useful idea that we knew we could get done in the timespan. That’s not to say we didn’t work hard to make it work as awesome as possible, but we also wanted to actually sleep. Ultimately this simplicity was probably why we won, though, as the idea was very easy to communicate in the presentation and we had time to focus on things like design. Rehearsing our presentation definitely was a key to winning though.
Now onto my next problem: What do I do with the the Parrot AR Drone that I won?
Parrot AR.Drone : Flight Demo from Parrot on Vimeo.
I came across this perspective on content and website development the other day:
It’s a simple and sensible concept, yet it’s often an ignored one. Too many web projects leave content for last, or at best somewhere in the middle, and that leads to all sorts of problems. Anyone who has been a part of a project where there’s a mad scramble at the end of the timeline to fix copy to fit a design that was only ever thought through with dummy text can tell you that.
Maybe you’ve had that kind of experience. Maybe you think it’s just part of the process. But it doesn’t have to be.
Content is the most important element of your website. It’s how your users get what they came for and it’s how you get your message across to them. This is not a place for cutting corners. A great design framing bad content will only get you so far, so take the time early in the process to get your content right. Let your content inform your design direction and you’ll end up reaching more people in lasting ways. Do it right and you’ll be prepared for the day after launch and beyond, because you’ll need to keep your content fresh going forward. What you need is a content strategy.
This is our approach at Elexicon. We can walk with you through what is often a difficult process of developing your content strategy, smooth over the rough parts along the road, and see you through to a successful launch and beyond.
Let us know how we can help.
Recently we’ve had an excellent opportunity to work on an HTML5/CSS3 Web App for the iPad. Everyone seems to be weighing in on whether Web Apps are comparable than Native Apps, and if eventually Web Apps are going to “take over” the space that Native Apps currently occupy. This is my perspective after having the chance to push HTML5 and CSS3 to their limits.
Note: In this post, “Web App” means an application that uses the new HTML5/CSS3/Webkit/JS techniques available on iOS to provide an enhanced user experience. It’s a lot easier than saying HTML5/CSS3/Webkit/JS. The term “HTML5”, while recognizable, is somewhat of a misnomer.
Web apps are created to work in Mobile Safari – so they can run just by having someone open up an iPad/iPhone and going to a URL. Additionally, many have also been creating “thin”, simple apps for iOS which just wrap the web app in a “Web View” – this approach allows them to get the application into the App Store.
As a design geek, the first things that I like to show people are the cool visual effects. Safari’s CSS Visual Effects Guide is a good place to learn about them, as well as their HTML5 demo site. Effects include reflections, gradients, dropshadows. and lots of 3D. CSS transitions and animations are fairly intuitive once you get the hang of them, but are definitely limited. The features all definitely have an Apple feel to them – I’m surprised they didn’t implement a “-webkit-shinytable” CSS property.
HTML5 has offline caching, so once you’ve visited a web app there is the ability to get to it offline. However, it does have a 5MB limit and files have to be added to a cache file manually, which limits the usefulness of this feature to apps which don’t have a ton of content.
There are all sorts of touch event handlers for JavaScript on the iPad/iPhone – you can even respond to multi-touch events in your browser window. There are a few quirks but you’re not limited much in terms of how the user can interact with the device. You can also easily change the look and feel of your app based on the orientation of the device.
UI Performance has to be the biggest difference between Web Apps and Native Apps – it’s the key limitation that prevents Web Apps from taking on most Native apps. Native Apps can take advantage of a lot of the underlying hardware that mobile Safari just doesn’t have access to or is too many steps removed from. Want to do a 3d rotation of something that has a dropshadow? It’ll flicker. Want to have stacked “-webkit-perspective” values? It’ll slow subsequent animations to a crawl.
It’s not a showstopper, but it is annoying and it will prevent you from doing everything you may want to do. When doing something natively, you have the ability to get into the guts of these effects and tweak things or write your own. In a web app, that’s not really possible, although I’ve picked up some tricks and will do a subsequent blog post about some of my observations.
Some cool things are definitely still possible – I implemented a “coverflow” picker of over 10 1024×668 pages of content (many with images), scaled down and rotated – basically, a lot of content to be scaling and rotating and animating like that. My first instinct was that it would crash horribly, but after a little tweaking it worked perfectly.
Web Apps in some ways can be like using a lawnmower where Objective-C is like a weed whacker. For many lawns, the lawnmower is all you’re going to need. It might be a little rough around the edges, but it’s worth the tradeoff since it’s easy. But if you’ve got weeds in your very delicate, precisely designed garden, then a lawnmower simply might not work at all.
Like the lawnmower, doing simple visual effects has never been easier. It’s a question of context and whether those effects are all you need. In many cases, Web Apps will be easier than pure Objective-C, but if you need to “break out of the box” and do something more intense or exact, you simply may not be able to.
This also fits the lawnmower analogy – pure Web Apps have a ways to go before they’re going to look as polished as Native Apps can. Not only is performance an issue, but loading is a big problem too. Assuming you’re doing a pure Web App and just have content online, there’s no way to prevent all of the flickering and flashing that goes on with loading a normal web page.
Also – users have to wait for your content to load. If they’re on a slow connection, they may be waiting a while if your application is complex. There are ways to mitigate all these things but they’re challenges that you will not have to face as much when designing purely Native Apps.
There’s definitely some powerful potential for hybrid Native/Web Apps. Some UI features may simply be easier to implement in HTML, and objective-c allows you to use “Web Views” which can reference local HTML content, so the two can merge.
For instance, say I wanted an image to come in dynamically to my Native App with a 3d rotation and reflection effect – I could consider writing a bit of HTML with some CSS3 for the rotation/reflection, and then using a “Web View” to display this HTML. But if I’m exclusively working in Objective-C, I may have to spend a lot longer tweaking a custom-made reflection effect.
Most things that are supposed to be magically cross-platform live in a special place in design hell, although this really deserves its own blog post. In a nutshell, there are far too many differences between platforms to expect applications to function well on every device without significant work.
For Web Apps, it’s still the same deal. Customization will still have to happen for different devices for an application to work correctly. Even using Safari on the desktop will be different if you wrote any “touch” event handlers for your application. Wider adoption of HTML5/CSS3 would quell some of these issues, but hardware differences still exist.
That all being said, it’ll be easier to make a Web App adapt to different platforms than a Native App, for the simple reason that a Native App would have to be completely rewritten for each platform. At the very least, most platforms understand HTML, so you have the option to gracefully degrade your Web App. Bottom line, though, is to not expect any magic here.
“HTML5” has gotten a lot of hype lately. This, combined with the high design standards of the platform, may lead people to expect a web app to both be cheaper and perform just as well as a native application (and be magically cross-platform). While this may be true in certain, very simple cases, it’s far from an accurate generalization. In any project it’s important to set expectations early and for everyone to understand that Web Apps, while powerful, are far from perfect.
As the president of an interactive agency, I of course often ask friends, colleagues, and new acquaintances “how’s your website?” Most companies have them, although many aren’t happy with theirs. I’ll continue to ask the question as an icebreaker, but today really the question should be “how’s your digital presence?” In the previous era of the Internet era, before Web 2.0, social media, and mobile apps, the minimum requirement for businesses and organizations was to “have a website and show up in search” as opposed to not having a site at all.
Today, only having a website is in many ways tantamount to the old threshold of not having a site. Your interactive footprint now needs to reach into social media and include a usable mobile interface. Without these, your business and brand could be missing out on a fast-growing audience that uses Facebook almost exclusively as their web environment, rarely venturing outside of this virtual parallel universe on the Internet (notice how www URLs are disappearing from print and television advertisements, replaced by Facebook and Twitter icons). In addition, more and more of your visitors are trying to reach your content from Blackberrys, iPhones, Androids, and iPads.
If your business or organization is considering building a new website or redesigning your existing site, you need to include social media, a mobile version, and possibly a mobile application as part of the “site,” by default. If this sounds intimidating, a consultant from a firm like Elexicon can help you create an efficient plan for navigating this new territory. These new frontiers don’t need to be expensive or triple the cost of your project, either. Talk to us! We’ll begin by looking at platforms, devices and audiences strategically and develop an optimal plan for your digital presence.
Related insights:
The article fanning the flames of the “Web is dead, long live the Internet” movement. We agree with some, but not all, of these points.
Thoughtful rebuttals from Mashable …
…and BoingBoing
Intervention Insights is a new medical service company in Grand Rapids, Michigan. Its mission is to improve the lives of patients afflicted with cancer through personalized medicine solutions applied by their community physicians. Their service was born out of research performed at the Van Andel Research Institute and continues to be developed through their team and partners.
Intervention Insights approached Elexicon as a startup company needing to get off the ground. But unlike many startups, there was really no time to ramp up — with a service to be marketed to cancer patients and medical professionals, Intervention Insights absolutely required an established presence and a clearly communicated message.
Intervention Insights needed branding, a website, and print materials that would both attract and inform two very different audiences: doctors, who needed to be brought onboard to provide their service, and patients, who needed to understand whether or not the service would benefit them. As a company in the medical field, Intervention Insights needed to show depth of knowledge, yet due to the nature of their service, be very approachable.
The details for its service are quite complex, but patients with cancer who can potentially benefit from the service need to know as much as possible. So in addition to a full marketing program, Elexicon was asked to develop overview videos to help patients and their loved ones understand enough about the service to be able to followup with their doctors.
Elexicon met with Intervention Insights’ marketing personal and subject matter experts to hone their message and develop a marketing structure. From this we were able to generate the logo, tag line, and other branding elements.
Intervention Insights provided starter copy, which Elexicon distilled and re-wrote for clarity and consistency. Once all were comfortable with the basic story, Elexicon turned to website and print literature development. For the website, we worked through a full process of wireframes, designs, mockups, and eventually a full beta site. The site was tested extensively before being successfully launched. The print literature was crafted to meet the specific needs of various audiences and included cut sheets, brochures, and quick-read pamphlets.
In addition, Elexicon produced two play-through video overviews, one for patients and one for physicians. These animated online segments explain in clear terms how the service can help doctors identify the optimal treatment path for a patient’s specific cancer, providing a starting point for patients, their doctors, and their families.
Visit http://www.interventioninsights.com for more.
During my usual breakfast internet browsing, this piece by Social Beat’s Kim-Mai Cutler caught my eye. In the piece, Cutler attempts to formulate a best-guess of Facebook CEO Mark Zuckerberg’s position on privacy. Until Zuckerberg himself comes out with actual long-form comments on the issue, this is about the best we’ve got. And it’s not encouraging.
In fact, I would characterize his views (as articulated in the quotes Cutler pulls) as incredibly naive. Not everyone in the world means well, Mark. There’s a reason people value their privacy and dole out information about themselves only to people they trust. And it’s not because they lack integrity.
That said, Facebook isn’t completely open. But, extrapolating after seeing how we got here, you could very well put a “yet” after “open.” And that’s scary.
Especially for those of us who got into Facebook back in the old days.
I first heard about Facebook in 2004, when a friend of mine who was attending the University of Michigan told me about it. At that time, you had to be part of a school network and the list wasn’t very large. Eventually, I was able to submit information on my university to Facebook using a tool they had for adding to the list. In September 2005, Facebook opened to my campus.
At the time, your profile was by default only as public as your college campus or your friend group. Very few people (more likely, no one) could claim to be close friends with everyone on campus, so even this limited openness was, in hindsight, a privacy issue. But hey, we were college students and part of a network that was just for us (no school administrators in those heady early days).
Eventually, Facebook opened up to local, city-related networks. You could limit visibility on those networks to just friends who were from Grand Rapids, but not part of your school network, if you wanted. You could also allow your profile to be open to the local network, if you chose. If you weren’t careful, you could run the risk of a privacy issue, but no big deal.
If you’re one of Facebook’s oldtimers, you no doubt remember the uproar over the News Feed feature. I myself never got the outrage, because all it did was make the fact that your profile is open to all your friends a little more in-your-face than it had been previously. If anything, it was a great feature that made keeping up with people easier, especially during the hectic later years of college when physically spending time with friends became harder.
But the point of the News Feed-and I remember a statement by Facebook to this effect-was to keep you up-to-date on what your friends were doing. That was the whole point of Facebook, to allow for that sort of automated aggregation of activities and information that helped make organizing events and get-togethers easier on top of keeping in touch when coursework took friends on different roads. When I graduated, this was a huge help as people I knew and cared about scattered to their actual homes and future careers.
But notice words like “friends” and “people I cared about” in the previous paragraphs. These were people who I wanted to know my music tastes, what movies I enjoyed, what books I was reading. These were people I wanted to know what I was doing, what my political views were, how I felt about whatever topic you could name. Facebook provided the mechanism to supplement relationships with people I actually wanted to have relationships with.
Obviously, there are and were other methods, such as, you know, talking, or emailing or IMing or any number of other tools. Facebook was one of many. But one we entrusted with private details within what’s been called a closed garden.
Mark Zuckerberg is opening the garden. Whether driven by the call of advertising revenue or by an honest desire to change social norms about privacy, he’s breaching the contract under which I signed up for his service. To some degree, he has every right to do so. Under the terms of use agreement none of us ever read, perhaps he gave himself an out, a route to this point.
And to some degree, we put ourselves in this position by feeding Facebook our stuff. Remember, it’s an opt-in service. In that I agree with this sentiment. But there was once a dream that was Facebook. It’s a dream that’s fading further with every loosening of the covers on our privacy.
I guess it’s our fault for believing Facebook would live up to the responsibility it took on by creating that dream.
As a sort of post-script, I have to say I don’t know what the solution is. Zuckerberg and Facebook have us captive, having created a massive network that most people we know have joined. There is no clear alternative (assuming we can trust any alternative to do a better job with our information).
Some people feel angry enough to leave. Those of us on the fence, who would like to reap the benefits of easy contact with our friends and family over great distances despite the privacy concerns, are held there both by 1) the specter of a life without the crutch we now sorta need and 2) the herd of people who don’t care enough about the privacy concerns to force a change.
One promising solution may be Diaspora. You can read more about it here. Unfortunately, it will be some time before it’s available.
Today, the ROI of a website is somewhat hard to calculate. While the building of your website may not translate directly into sales or new customers, the lack of a website or having a bad website can greatly damage your credibility as a company. This loss of credibility can have much more far-reaching effects than just losing sales. For instance, prospective employees may be examining your company’s website to determine if they want to work there. The general consensus is that investing in your web presence is rewarding, even if it is difficult to quantify.
Email Marketing is a different game, though no less rewarding. It’s much more similar to running an online advertisement, as you are able to directly track the effects of the email campaign and see exactly how many conversions it leads to. For those who aren’t familiar with the term, conversions can be any particular goal you have for your users. A user buying a particular product, a value based on the dollar amount of their purchase, or simply filling out the contact form on your website can all be called “conversions” – it all depends on the goal.
Unlike websites, not doing an email newsletter will probably not hurt your company’s credibility. However, bad looking or scammy email newsletters probably WILL hurt your company’s credibility – which is why we’re here to help.
Just the ability to track ROI is great and all, but obviously it won’t matter if email campaigns aren’t effective in the first place. So, are they? In February/March of 2009, Forbes commissioned an Ad Effectiveness Survey which ranked email and e-newsletter marketing as the second-most effective tool for conversions (source ). Email Marketing Reports has more great statistics on why email marketing is effective, including a report that states that, on average, commercial email returns $43.62 for each dollar spent. The results are pretty conclusive and indicate that Email Marketing should NOT be ignored.
Ultimately it also comes down to your audience – I certainly won’t sit here and tell you email marketing is effective for every customer base or in every situation. However, the unique ability to track ROI and the fairly low cost barrier to entry means that it pretty easy to determine if it’s a worthwhile marketing strategy for your company.
In software development—and large software projects in particular—there’s a pretty big problem. They fail too often. Far too many come in late, over-budget, and lacking any sort of maintainability.
2010 Michigan Agile and Beyond was held last Saturday, and it was all about one of the most popular ways companies are dealing with this issue: Agile Development. I was glad to be able to attend, and very impressed with the presenters and their ability to explain what Agile is really all about.
There’s a lot to be said about Agile— whole books are written on the subject—but I’ll attempt to quickly explain what it does and where it’s an appropriate philosophy. These are the ideas that stuck with me and the ones that mainly revolve around development, though there’s much more to the entire Agile method, especially regarding communication. The main points of the “Agile Manifesto” can be found here: http://agilemanifesto.org/
A commonly cited source of problems is simply that requirements change. At the beginning of a project, developers ask for a full specification of what the customer wants. The customer may even provide a spec that’s pretty complete. But as anyone who has worked long as a developer will know, it is inevitable that these requirements and specifications will change and be misinterpreted. These issues frequently aren’t discovered until the very end of the project when things are supposed to be finished. Customers aren’t really the ones to blame for this. The world simply changes, and large software projects are too complicated and have too many exceptions and rules for any one person (regardless of talent) to be able to visualize it completely, even in a specification document. It’s simply too big.
This problem often reveals itself in the code. If the developers are using a “waterfall” method, where the customer often doesn’t see the product at all until the end, the developers will often have to “hack in” a bunch of changes at the end to fit what the customers want and still stay under deadline. This leads to a messy codebase.
On the other hand, “rapid prototyping”—giving customers a new version of the software to look at very often during the project—often isn’t sufficient to solve these issues either. Those prototypes are usually developed with the mindset of “I’m going to refactor this later and make it more maintainable.” Unfortunately, the refactoring and simplifying rarely actually happens. When it does, it often introduces new bugs as dependencies are forgotten, another symptom of the system being too large for one person to visualize.
Although rapid prototyping isn’t ideal, it can often work better since it at least acknowledges that requirements will change. It gives customers the ability to easily figure out what they want since they will see a working version of the software in front of them. However, as stated previously, on its own it doesn’t always lead to a quality product. To solve this issue, Agile introduces Test-Driven Development to the rapid prototyping process.
Test-Driven Development (TDD for short) is about automating the testing process. In normal development, testing is often confined to just a week or two weeks at the end of a project and is done entirely manually. Not only is this often cut or reduced as projects get closer to the deadline, but it’s a great deal of wasted man hours and must be repeated when changes are made to the system.
The idea behind TDD is that developers write tests for their code BEFORE writing the code itself. Initially, it may seem absurd that one would code something that would fail a test they had written just a few minutes previously. But the benefit of the test is not to ensure the code does what it’s supposed to right then and there; it’s mainly to ensure that the code does what it’s supposed to regardless of what else changes in the future. Large software projects are very interconnected, and changing one small part often has implications for many other parts. The tests ensure that when you change something, you aren’t accidentally breaking the other pieces of your system.
A philosophy of Agile development is that software projects should respond to change, and TDD is a requirement for this to happen. In non-TDD development, a customer will ask for a change to the software or add a new requirement, and the developer (if he’s careful) will have to check through everything that could potentially be affected to ensure that new bugs aren’t introduced. With TDD, he would simply make the change, run the automated tests, and get an immediate report of whether his change broke anything else. He would also be much more confident in immediately showing his change to the customer because he would know that he had not introduced any new bugs.
TDD also allows for greater ability to continuously refactor and simplify the code, which Agile encourages. Refactoring introduces the same issues as making small changes to the code: you don’t know what else in the system might be broken because of changes you make. TDD solves this in precisely the same fashion, because it can automatically test your code once you’ve made changes.
The advantages outlined here come down to this: much less manual testing, the ability to have very maintainable code, and the ability for customers to give constant feedback on the latest version of the software.
It doesn’t come free, of course. Agile is really an investment in coding infrastructure. There’s a good deal of initial work required to ensure the ability to release software to your customers on a regular basis. There’s also an ongoing cost of writing tests for every new piece of code. But this investment really pays off for many large projects that need to respond to change, because you end up finishing more quickly or further under budget due to the reduction in bugs, testing time, and misunderstandings. That’s not to say every project may finish more quickly though. For instance, very small projects may not get their investment back, because the projects might have simple requirements that don’t change.
Finishing more quickly is great, but even if that doesn’t happen on some projects, there are other advantages to this method. Let’s say, for example, that there are two identical projects—one attempted with a waterfall methodology, one attempted with an Agile methodology, and both doomed to go exactly the same amount over budget and past deadline. The advantage for the Agile project is that all parties would have known this outcome was coming much earlier in the process, and so would have been able to plan for it by reallocating resources or canceling the project.
Agile’s goal is to mitigate the risk that’s taken on by every party involved in software projects, and for many projects it’s very effective at accomplishing this. The statistics on software projects in general aren’t pretty, and there’s a lot to be said on the low bar some projects set for “success.” Hopefully, with further adoption of techniques like Agile, software projects can come to be seen as much less of a risky investment.
Let’s talk about your old website, the one you had built in 1999. The one you’re privately embarrassed about. The site you include on your business card and in your print advertising materials because everyone else is doing it, even though you’d rather potential customers call your number than actually sit down and click through what’s currently sitting at www.yourcompany.com.
You’ve put off seeking out a redesign of your site for years, thinking you couldn’t justify the cost for what might be a niche advertising arena. Print marketing rules, you say. Sure, the younger set may prefer to learn about your product or service on the Web, but the majority of people will be looking you up in a phone book or reading your ads in the paper. Or so you tell yourself.
But now, with traditional newspaper readership down, and phone books being replaced by newer, jazzier online services, you’re starting to get that nagging feeling that your company needs to catch up. Or rather, pull ahead of the crowd with a really great redesign and a new, 21st-Century marketing strategy. But how? You don’t know the first thing about web design agencies in your area. All you know is you need to find one, because you don’t want your nephew to build this thing, even if it means you can pay him with a Wii. Your nephew’s a cool kid, capable in his own way, but you want professionals.
This being the Elexicon blog, you know what I’m going to say next: use us. We can help. Here’s how.

Content
Perhaps one of the things holding your current site back is content. Like its design, you still have content from 1999. You may have tacked on some newer, more relevant information, but you’ve still got a hodge-podge collection of content with no real direction or form relevant to what your company is in 2010.
We can help with that. We can work with you to determine what you want to say to your customers as they go through your site. It may involve re-working the old content or it may involve working up wholly new content. Either way, we can come up with copy that is appropriate for your new site. And we specialize in methods of organizing this content in ways that fit best practices to optimize returns. We’ll help you convey your message.
And we can be there after your site launches to help with content maintence, which will prevent that content from becoming stale again.
All of this is important because what you say to your customers with your content has a direct impact on their decision to buy your product or use your service. If your content falls short, your site falls short.
Design
Your site was designed in 1999. The Web has made some giant leaps since that time, and unlike much of popular culture, those leaps haven’t led full-circle to retro being in. A 1999 style doesn’t cut it.
Your site’s design is what offers your customers a first impression of your company. If you have great content that masterfully sells your product offerings but your site’s design isn’t attractive, visitors may well miss out on your pitch as they bounce on to another site. The last thing you want is for prospective customers to bounce away to a competitor’s better-looking web site.
That’s all surface level stuff, you might say, We go deeper than that. You know that. I know that. But the customer doesn’t. The old dictum “don’t judge a book by its cover” is definitely not practiced on the Web. People think if your site design isn’t quality, your product or service probably isn’t.
So, here’s where we come in. We can come up with a great design for your site, one that will catch the customer’s eye and pull them in so that they see what you have to offer. We’re really good at this. And if you’re thinking your logo needs a refresh, we can help there too.
This is the most up-front way you can stand out from your competitors on the Web. Play to the fact that people are wowed by a sharp design and then reap the benefits.
Build
The technical side of all of this scares you. You’re not a computer whiz that can work magic with a keyboard. Don’t let that stop you from starting this. We handle all of that. Your site will be built using the latest industry best practices and newest technologies. And we can put it all on a platform you can use yourself, computer whiz or not.
We’ll make it fast and responsive to avoid the other issue that makes people bounce from your site: slow load times. We can provide on-going support for you to keep your site running into the future.
Grow
We also offer services that will help your Web presence grow after launch. A new site isn’t everything. You need to plug in to the current modes of online marketing, which go beyond text ads (but can utilize those, too). We can help you formulate a social media strategy and then help you get started connecting to customers on Facebook, Twitter, or a blog, or whatever’s hot tomorrow. We can also help with more traditional forms of marketing, if you’re looking for guidance in those areas.
Move Forward
It’s time to bring your site out of 1999. We can do that for you. Get in touch today.
Grand Rapids based Value Health Partners (VHP) is committed to creating greater value for patients and the community and is comprised of eight regional health care systems in Michigan. We were thrilled when they asked Elexicon to design and develop their new public facing consumer site along with a secure member site. The secure member portal enables users to work together on a variety of activities and would also require that access be limited to a defined subset of the users. Data security was a critical component to this group.
Elexicon was presented with a few challenges on the VHP project. On the one hand the client would be managing their content internally so they needed a content management system (CMS) that was simple and easy to use yet offered all of the security and collaboration functionality necessary to meet their specific needs.
While on the other hand Elexicon needed to design a clean, sophisticated site that appealed to three diverse user communities: medical, legislative and the general public. Information needed to be delivered quickly and effectively without a lot of clutter. And, most importantly, the design needed to work with in the CMS.

Elexicon partnered with Blue Sphere, a Grand Rapids based software consulting firm, to create a Microsoft SharePoint site for both the internal and external audiences. Elexicon provided the project’s creative direction, design and CSS expertise and Blue Sphere developed the Windows SharePoint Services (WSS) environment.
The clean design was meant to appeal to a more broad range of audiences – physicians, governmental officials as well as the general public. The main Flash visual promotes the wide reach of the members throughout the state of Michigan. This animation can be updated with virtually any message that VHP wants to convey.
The site structure was designed to be flexible and can be maintained by the client using the easy to use user interface. Blue Sphere and Elexicon trained the content administrators in just a few sessions. VHP will be solely responsible for keeping their site up to date.
Visit http://www.valuehealthpartners.org to see more!