Goose

In the previous post I talked about how my wife had mentioned that maybe I could build her an app to help her manage our new baby.  When I tell this story in 10 years time I’m sure I’ll be telling it slightly differently and more like this:

My Wife: Take me to bed or lose me forever

Me: I’ll build you an app instead!

#Romance

Now back to my post and the continuation of Part 1 of the Wife App:

I started the discussion by deciding that I needed a new profile, and talking to her about what she wanted to be able to measure.  I didn’t care what a report might look like, just the data points that would be required.  Based on the discussions it was pretty straightforward and for now was two objects:

Object #1: Diaper Change

  1. I need an auto-number for the name
  2. I need Date and Time
  3. I need Type (I’ll spare you the details, but apparently this is important to track)

Object #2: Feeding

  1. Auto-number again – why would you ever name a feeding?
  2. Date and Time
  3. What side was used (which boob for the people without kids)
  4. Whether formula was required to supplement
    • If so, how much formula was needed to supplement

I created the fields and basic page layouts for both, along with a new publisher action for each one.  I’ve been through publisher actions in quite a few of my previous posts so I won’t go over them again.  Read my Mileage Part 2 post for more information on these.  I just posted on the success forums yesterday that if you don’t take the time to do some proper publisher actions you might as well throw mobile adoption out the window, and they are really easy!!!

What I will say is that I decided to create a new Global Publisher Layout  called Family Layout and assigned it to the Wife Profile

Family Layout

This has nothing to do with wanting to limit her ability to post a poll or URL, and everything to do with making it as simple as possible.  Too often with Salesforce I’ll see people not spend the time getting rid of the noise.  Put yourself in a new mother’s shoes for a second – these things are literally all you care about right now and even a general post is debatable.  Get rid of everything else not for security, but for ease of use and a simplistic user experience.

Reporting

One of the nice things about building out reporting here is that she hasn’t been making custom Excel charts and Powerpoint decks for the past 10 years that she thinks can magically be replicated in Salesforce.

I started by building a very basic dashboard and just making sure that it also works in Salesforce 1 (which it does).  Simple, to the point, high level information.  My wife does not care what happened a month ago in terms of feedings, she is tracking current state to make sure nothing drastic has changed.  Later on we can go back and look at overall growth metrics.  So without further ado here is what I created:

Baby Dashboard

Again,

  1. Basic
  2. To the point
  3. Easy to look at
  4. Easy to reference back to

All attributes of a good dashboard in my opinion.  Until people get used to them, try to keep some consistency with the look at feel across rows and columns (at least in my opinion).  There is less reason for them to stop because they don’t understand and ask their analyst to just send them the numbers in the old format instead.

Reporting/Analytics in a Business Setting

I want to do this brief paragraph because I find that a lot of users and even Admins don’t know enough about the reporting engine, and don’t know what to ask for.  Don’t even get me started on end user requests.  So here is how I like to do it:

I like to handle reporting wherever possible as either a joint exercise with one business user who has the power to make decisions, or by taking a first run at them myself to show the business what I think makes sense based on the requirements that I have been provided.  One of the big frustrations is that Salesforce reporting is not a full ETL backed BI tool.  Your reporting options are limited.  Business users will admit that they have a team of analysts preparing reports every week, and doing manual intervention prior to creating them, but still somehow expect them to magically work in Salesforce.  This just isn’t a reality.  Whatever you do, be careful with what you promise from a reporting perspective.  The best way is to say that you will do your best to replicate the reports within the Salesforce framework, but that the business must be willing to accept a different look and feel compared to what they are used to.  Otherwise you are into Visualforce and custom code.

I promise there will be more to the Wife App than Feedings and Diapers.  Just yesterday she said she could use a grocery app, I’m hoping to expand things a little bit past that, get her to think bigger.  I told her we could share the groceries app, and subsequently scored bonus points.  We’ll see what comes up and if she’s lucky maybe she’ll find an enhancement deployment in her Christmas stocking next year.  I’ve got at least one more post on the Wife App project coming as well, there are already enhancement requests starting to roll in.  I like to let the users settle into something for a bit before making changes, let them really think about what they actually need, so I’m going to pivot over to something else for the next few posts, most likely around an upcoming Wine App and some other things I’ve been working on.

Any questions can go here, Twitter, or to my success community profile which can be found top right of the screen

 

 

 

Share Button