Perficient Portal Solutions Blog

Subscribe to RSS feed


Follow our Portals and Social Business board on Pinterest

A Day in the Life of a Social Media Manager

In the BufferSocial blog, Kevan Lee posted an article for Social Media Managers.  The post takes a look a “typical” social media manager’s day and breaks down that day into many different activities, represented in the info graphic here.   

Mr. Lee also provides several different views on how other people spend their days managing social media.  One person, Finola Howard, manages to compress all her daily activities into just one hour per day. Her tasks include:

  • Use SocialOomph to figure out which new twitter followers to accept
  • Measure which posts are performing the best so you can take advantage of them
  • Schedule tweets and posts for the day.  She uses Buffer for this, other use tools like Hootsuite.
  • Find content
  • Respond to others
  • Monitor engagement of fans and followers

In general, the post identifies 12 tasks of a social media manager.  The twelve tasks are shown here and the article does a great job of explaining each of them.

If you manage social networking within your company, say using IBM Connections, Yammer, Jive or others, you should also pay attention to the tasks.  Each of these 12 tasks apply to internal as well as external social managers.

In addition, Mr. Lee provides a series of checklists for the social media manager.  These lists come from places like Mindbrew Creative, HeroX, Hootsuite and others.  Even by itself, the various checklists are well worth your time to understand.

Overall, A day in the Life of a Social Media Manager is extremely valuable and full of great information.

How to Implement Lighter Weight Portals, Part 3: Knockout Portlet

In this series, I’m showing how Portals don’t have to be heavyweight.  In Part 1, I wrote about how to make the infrastructure lighter by using cloud or IBM’s Pure System.  In Part 2, I introduced the concept of using IBM’s Web Content Manager system to build very simple portlets.

Now in this final installment, I am going to extend the concepts introduced in Part 2 to show how we can build more complex portlets, but still keep everything lightweight.  To review quickly, in Part 2, I avoided the build and deploy cycle of building Java portlets by using the built-in content management system – WCM.  In that example, I used WCM to display a Reuter’s news feed from a simple Javascript widget supplied by Reuters.

My Appointments Portlet

Final Appointments Portlet

In this blog, I want to implement a more complex portlet using Knockout, which is a popular Javascript framework.  My example is to display in a portlet a list of my Doctor Appointments pulled from a REST service.  Our goal is still to keep this lightweight, so I shouldn’t see a lot of code.  The first screen shot shows you what the final version looks like in Portal 8.

A typical web page or application consists of several sections:

  • CSS
  • Links to external files
  • HTML body
  • Javascript

In WCM, we can create an authoring template that contains four HTML fields, one for each of the sections described above. The authoring template also has a workflow associated with it so we can control the publishing of our code.
Read the rest of this post »

How to Implement Lighter Weight Portals, Part 2: Portlets

In part 1 of this series, How to Implement Lighter Weight Portals, I wrote about the infrastructure and installation aspects of Portals. To make the tasks of managing and installing portals, I recommended cloud solutions and for IBM, their PureApplication system both in the cloud and on-premise.

In Part 2, I turn my attention to applications and how to make task of developing portal applications more lightweight.

The goal of a portal is to combine applications and content at the glass for a user.  By this definition alone, we should always think of how to make lightweight portlets.  If you have a larger application to build, break it down into core components that can be built into separate portlets, rather than one large portlet.

Even if you can get to smaller, bite-sized applications or portlets, you are still faced with the underlying framework imposing additional layers on your efforts.  We’ll focus on Java-based portals to make the discussion simple and I’ll use IBM WebSphere Portal as an example.  Say we want to simply display a feed from Reuters as shown in our first picture here.

Reuters News Service

Reuters News Service

Reuters provides the javascript, so all we need to do is put it into a portlet for display on our page.

To create a portlet for use in IBM WebSphere Portal, a developer is going to use IBM Rational Application Developer (already a heavy-weight tool), create a new project using a wizard, fill in some details about the portlet, like name, Java version, etc.  and then hit go.  RAD will do a nice job of building the portlet shell with all the right components set up.  These components include xml files, TLD files, libraries or references, file folders and start JSP files.  Already, we have a lot of code to manage.

Once I put in my custom code, I then have to build the project, create a .war file, and then deploy it to WebSphere Portal. After its deployed, I can create a portal page, and my new portlet and I’m all set.  In most IT shops, build and deploy to production can take weeks or months just because IT has to control the changes to production very tightly.

If I’m a business guy who just wants a very simple portlet, this makes portal look heavyweight to me, but its likely the process than the technology.

So how to fix this?

Read the rest of this post »

Using Mapping to Show Up-to-Date Content

Sometimes I’m amazed with what some of our developers do.  I’ve seen so many examples of code just thrown together. I’ve seen that code produce infinite loops, slow down load time by a factor of 10, and take down servers.  So when I see an example of someone thinking through how to efficiently create code, I’m amazed.  Anyway, Parshva Vora, a Sitecore developer here at Perficient, just blogged on how you can use mapping to create agile code and more efficiently get at the latest content.  I’ll use some of his own words

Using Mapping to Show Up-to-Date ContentLet’s talk about motivation first. I was dealing with a problem involving aggregate object where information needed to be retrieved seamlessly from various and diverse data sources including search index without spreading data access code into my models and views. Does’t it sound like classic case of data mapping problem? In fact, Sitecore 7 content search APIs similar approach where indexed content is filled into specified .Net object(typically into SearchResultItem or its derivative). And mapping is directed through IndexField, IgnoreIndexField and few other attributes. Now it begs an obvious question, why would I use Glass.Mapper? Consider following scenario:

Say you are dealing with an item with large number of fields and not all of them are being indexed(indexing comes at a cost so you like to index select item fields, for instance fields that appear in search results). And while processing search results, some of those non-indexed fields need to be referenced. One way is to make sure that the ID field gets indexed and then using ID, you retrieve related item from database. However the process could be non-transparent and messy, particularly if field is complex or nested field type and there are several fields. So instead of you pulling information from database with Sitecore APIs, Glass.Mapper can do it for you, with the help of mapping attributes. Consider following model for an article where its number, title and summary are retrieved from index and content and images are retrieved from database.

Parshva goes on to get into how it works and to show the benefits of the mapping approach.  It’s worth reading the whole article if you have similar needs.

Why Patient Portals Remain Healthcare’s Enigma has an interesting article about why patient portals just aren’t popular.  I think the author, Brian Eastwood, gets some things right but also misses some key reasons or challenges.  Here’s what he got right.

  1. Why Patient Portals Remain Healthcare's EnigmaAdoption just isn’t very high. No one is using the patient portals that are out there.
  2. Doctors don’t use portals………….and they don’t have patients who use portals.  In other words, if a medical provider still thinks the best way to communicate is when someone is sitting in front of them then things won’t change.
  3. The features don’t match what your users want………. and herein lies the rub.

Now I don’t disagree with what Brian says. I think he makes a number of great points.  But I also take issue with one point he makes:

So what will get patients to use a portal? It’s not as hard as providers may think. The functionality that patients told Software Advice that they want – scheduling appointments, paying bills, viewing lab tests, refilling prescriptions and emailing staff – should sound familiar (on the face of it, at least) to anyone who regularly uses ecommerce applications.

Here’s the reality.  Patient portals are hard. They are harder than many ecommerce or consumer sites that sport similar functionality.  Frankly, they aren’t that much harder from a technical perspective but there are a number of issues getting in the way.  Let me name a few of them.

  1. Healthcare in general is still coming up to speed in their technology evolution.  You don’t just launch a bill pay option without a hook to both your billing back end system and a payment gateway.  Both are foreign concepts to many healthcare providers.   By providers I mean doctors and hospitals.  So slapping a front end onto something isn’t going to solve your problems.
  2. Healthcare is a mishmash of systems that never wanted to communicate with each other and weren’t architected to do so.  I can tell you about hospitals who have a patient pre-register online and then pay someone to key that data into their EMR because the EMR doesn’t have any hooks. I can tell you about trying to pull certain data from an EMR and then missing key information demanded by MU2.  Many companies are springing up whose sole job in life is to allow you to schedule an appointment online because of the variety of systems without proper hooks.
  3. Healthcare is comprised of many, many, many separate entities.  You may find a doctor on a hospital site or an insurance site but they are only affiliated to the doctor at best. That doctor won’t support a common standard to let you query their scheduling system and make an appointment.  This disjointedness leads to challenges.
  4. Doctors don’t like spending money on technology.  Yes, there are exceptions but most would far rather build a new office, add on a hospital wing, or buy a cool surgery robot.  Many think of technology from the standpoint of their tablet or computer and don’t understand the complexities of multiple server systems supporting high uptime, disaster recovery, security, etc.  Lack of funding until very recently means you have so much further to climb.
  5. Conflicting government rules make it difficult to create a good patient experience.   HIPAA demands you keep all patients data intact.  MU2 demands you open up that data to your patients.  Specific rules within both conflict.  People in charge of security within these healthcare organizations tend to take the least risk approach and demand multiple levels of security that adds to the expense very quickly.  Let me give you the most common example of how this can go wrong.  I know of multiple hospitals that only let you register for the patient portal in person and with your id.  Using your patient id, unique number from your last discharge, and common questions from your credit report all fail the test.  Only an in person visit will do.   If you want to see and manage healthcare for your child, that only adds to the complexity.  This means that in order to run a successful patient portal, you have to modify your business processes to have front office and discharge people do one more thing and do it in a secure fashion.
  6. Most out of the box patient portals………and I use out of the box very lightly here, only support you accessing your medical record.  They don’t even do a great job of that. These EMR based portals let you see your lab results but they don’t help you interpret them.  They are sometimes very hard to read.  These portals don’t provide access to bill pay, find a doctor, pre-registration, classes and events, or schedule appointments.   They don’t personalize the experience and tell you about your care team.   Many of these portals have no plans to add these types of functionality into their patient portals because adding these features is hard given the diverse number of systems out there.

I want to make one final comment which Brian gets right in his article.  I think that with lots of room for improvement comes a lot of opportunity for healthcare providers to truly engage their patients.  A lot of these providers are looking to the future and asking what it will take to do true patient engagement and to add in features like sensor uploads, better reporting, proactive personalization that helps you understand what’s in your medical record etc.  So while it’s an uphill slog, the future is bright.

How to Implement Lighter Weight Portals

One of the complaints we often hear about horizontal portal systems is they are complicated and feel “heavy”. What makes a system feel heavy and how can we lighten the load?

In a typical portal application we have to integrate multiple applications, content and document management systems, security, search, personalization, page management, etc, etc. is it any wonder why a portal would feel heavy when you try to bolt together all these systems? Some vendors have taken the approach that they will build all of these components into their horizontal portal, which makes them seem heavier out of the box. Other vendors go lighter out of the box, but then put the burden on others to integrate the missing parts.

Given that portals are naturally heavy, what can we do to lighten them up or make them appear lighter?

First, let’s talk about requirements. Do you really need all these systems integrated to accomplish your goals? If not, maybe simpler web pages built off simpler content management systems maybe all you need. For example, if your site is going to be content only or mostly content, then you probably don’t need a full blown horizontal portal.

But let’s assume a horizontal portal makes sense. Then you’ll likely need the portal software, an application server, a database server, an http server, a security system like LDAP, and maybe a few other servers just to get started. From an install and infrastructure point of view, that is a lot of heavy lifting to install all those servers and get them to work together.

To make this infrastructure lighter or appear lighter, we can turn to cloud vendors, or in the case of IBM their PureApp system. Let’s look at cloud vendors first.


If you’ve kicked the cloud tires yet, you know it is fairly easy to get individual servers up and running. You can request a database instance, an http server, security, and an application server and have it running in minutes. In the portal world you may still have to install the portal server separately, but some vendors are able to have that provisioned too. In most case you still have configuration steps to take to get all of those servers to work together. Still the cloud makes the portal infrastructure feel lighter because you didn’t have as much work to do to get it running.

What if you can’t go cloud and have to stay on-premises? IBM has tackled that problem with their PureApplication System. With PureApp, IBM has defined system patterns and has created the tooling necessary to implement the patterns automatically. For a portal environment, an IBM pattern looks like this: two portal servers clustered, an http server, a db2 server, and a Websphere Deployment Manager. That’s a lot of servers and configuration and feels heavy.

In PureApp, with this defined pattern, the system can install and configure a complete WebSphere Portal production environment is less than an hour. Five servers, fully configured and operational in less than hour. Now that feels much more lightweight. My colleague Kate Tuttle just posted an article on our Healthcare Blog about how Blue Shield of California used PureApp in their portal implementation project.

In the next part of this post, I’ll talk about how to make portlet development lighter weight. Here is a link to part 2: How to Implement Lighter Weight Portals, Part 2: Portlets

Forrester Digital Experience Wave

Last week Forrester published their first Wave on Digital Experience Platforms.   I was at the IBM Digital Experience Conference and it sounded like IBM was expecting good news from Forrester in this wave.   In fact, Stephen Powers from Forrester was the Keynote speaker at the conference and one of the principal authors of the Wave.  Forrester Wave

Much to every one’s surprise, the Wave came out with nobody listed as a Leader.  Adobe, hybris (SAP), IBM and Sitecore came out as the Strong Performers followed by many others in the Contender category. Nobody was listed as a Risky Bet.

So what gives?  Really no Leaders?  Dom Nicastro wrote a story last week about this development: Forrester Wave: No Leaders in Digital Experience Delivery.

Forrester considers a Digital Experience Platform a full end-to-end delivery platform and most vendors fell short in the completeness of their offerings.  Each vendor seemed to shine in one or more areas, but nobody stood out as having all the components needed to be a Digital Experience Leader.

For me, part of the issue stems from how Forrester defined the market.  hybris from SAP is strong in Commerce, while Adobe and Sitecore are more known for their Web Content and Marketing capabilities.  So the companies included in the wave are really all over the map, in my opinion.

Is it fair to compare commerce systems with WCM systems?  Yes and no.  If you need commerce in your digital experience, then you want to know who has commerce capabilities.  If commerce isn’t important, then no and the analysis gets skewed.

There is a lot of interesting information in the Forrester report, so I encourage you to read it yourself.

WebSphere Portal and UI Myths and Facts

I don’t know how I missed it but Harish Bhavinachikar has a nice post on what you can do with modern UI tools in WebSphere Portal.  It’s on our Spark Blog but addresses something that keeps coming up again and again.  Frankly, the front-end tools have changed considerably in the last couple years.  Modern UI tools / frameworks like AngularJS, Bootstrap, JQuery, and a host of others make it easier to manage the UI and to further enforce separation of the front-end from the back-end. While a horizontal portal like IBM’s WebSphere Portal does some of that, it wont’ take you all that way.  But as Harish explains, all is not lost.   You can still leverage those frameworks and best practices within the portal.  I’ll let you read the entire post but here’s his list of Myths. Note how he is also telling you some best practices here.

  1. WebSphere Portal and UI Myths and FactsMyth – Websphere portal is not compatible with latest front end frameworks like bootstrap, foundation, jQuery Mobile, etc.

  2. Myth – Websphere portal is not compatible with jQuery and associated plugins.

  3. Myth – All the css, javascript, images associated with a portlet should be inside that portlet.

  4. Myth – To make a change in the css file, this should be done in the portal theme, deployed to QA, tested and then served to production.

  5. Best Practices a Front End Developer needs to follow while working with portal theme.

Migrating Web Content Using Kapow (Part 3)

I’ve blogged about this before with Candace’s Part 1 and Part 2. She just published Part 3 in the series.  Here she focuses on what to do once you’ve extracted and transformed the content.  In other words, getting that web content into the target system. In this case it’s Sitecore, a popular .NET based WCM.  I think it’s great Candace took the time to walk through a step by step approach to this.  Go to her post for the full set of steps and details.

Once data is extracted and transformed, the clean data is sitting in database tables ready to be uploaded into Sitecore. Sitecore has an Item Web API available for uploading data, but it is limited to basic retrieval, creation, and update operations. How was I going to tie related records together? How could I perform basic if/else operations that were necessary? It was obvious almost immediately that the Item Web API would not be adequate.

Because I had so much system specific processing to do, I decided to write my own upload process, using the Sitecore API. If this were an ongoing process, it would have been necessary to build a more automated, flexible way to upload this data, but because it was a once and done operation, and time was short, the solution outlined below was sufficient. I wrote a rather ugly web page that allowed me to click through the upload process quite quickly:

You can also see some of what Candace describes at a much higher level on Youtube

Google Search With Salesforce

Brendan Callum, a director and whiz extraordinaire in our Salesforce practice, has a video out about what they did with Google Search and Salesforce. The video doesn’t go into a lot of detail but I find it extremely interesting that an appliance (older trend) searches the cloud (ongoing trend) in a secure fashion.  Of course, why do you need detail when someone developed a connector for it and all you have to do it buy, install, and go.

Update: Adding links to Brendan’s posts on the subject. Making Search Work in Communities Part 1, and Part 2 (with pictures)