About the Author

Danny is a Senior Software Engineer at InterKnowlogy in Carlsbad, CA. Danny began acquiring his expertise in software engineering at Neumont University in Salt Lake City, Utah where he graduated with a BSCS. Danny’s passion for technology has led him throughout the Microsoft Stack including .NET, C#, XAML, and F#. Danny has an expertise in NUI (The Natural User Interface) having built numerous multi-touch and gesture based interfaces for software applications across a broad spectrum of devices. Currently his passion includes building Windows Universal Apps and WPF Applications driven by gesture interaction using the Microsoft Kinect. Danny is an Alumnus Microsoft MVP for Windows Platform Development and speaks all over the country including That Conference, Spark Conference, and SoCal Code Camp. When not building beautiful software, Danny is an outdoors man and devoted husband and father. He loves to camp, hike and mountain bike. Follow him on twitter @dannydwarren

C# to F#: I’m a Convert

In my previous blog post C# to F#: My Initial Experience and Reflections I wrote about learning F# and converting a C# formula model into an F# formula model. As of writing my previous post the jury was still out on performance. I am very happy to say that I have some very quantifiable results and I’m ecstatic to announce that F# took C# to school!

Formula Model

The formula model we created can be found here. The structure is essentially: Model contains many Leagues. A League contains many Divisions. A Division contains many Teams. A Team plays at every Stadium thus creating many StadiumTeamData objects. Each Stadium contains details. In the excel file you’ll find 2 Team sheets, a LeagueSummary sheet, a Stadiums sheet, and a Stadium Schedules sheet. The Stadium Schedules sheet contains the schedule for each Stadium found in the Stadiums sheet which is only a list of Stadiums and their details. Each Team sheet contains StadiumTeamData (a row of data) which is the lowest form of calculation in this model. The LeagueSummary sheet sums the 2 Team sheets and calculates 10 years of data which can be used to create a chart. Our sample apps do not chart as our test was not about prettiness, but rather about performance. The excel model is a very simple model. It was used only to prove the calculations were being performed correctly. In the source code included at the end of this article you will notice the existence of 2 data providers: MatchesModelNoMathDataProvider and PerformanceTestNoMathDataProvider. The matches model provider matches the excel scenario with 1 League, 1 Division, and 2 Teams and 2 Stadiums and a single mandatory Theoretical Stadium. The Los Angelos Stadium is ignored in code. The performance model however has 2 Leagues. Each League has 9 Divisions. Each Division has 10 Teams. Each Team references 68 Stadiums. There is also a single mandatory Theoretical Stadium. This gives a grand total of 12,240 StadiumTeamData instances. These instances represent the bulk of the formula work and in the case of PDFx the bulk of property dependency registrations.

Implementations

C# and PDFx

The first implementation we created was in C# and uses the PDFx (Property Dependency Framework). This implementation represents the pattern we have used for the last year for client implementations. Due to familiarity this implementation took about 16-24 hours to implement. Which is pretty fast. This is why we really like the PDFx. It helps to simplify implementation in C#. Because PDFx is a pull based approach no custom events are required. The PropertyChanged even triggers everything under the hood for the PDFx. There is a catch though. This means that each property in a chain of dependent properties will raise the PropertyChanged event. In our example of 12,240 StadiumTeamData instances this means that PropertyChanged is called roughly 500,000 times just on the first calculation of top level data. With all of the properties in existence properties are accessed 2,487,431 times and of those 1,176,126 are doing work to setup the required property dependency registrations. So at the end of the day the C# with PDFx implementation takes about 55 seconds to load the object model and another 24 seconds to run the first calculation for a grand total of 79 seconds to load the application. Another really bummer part of PDFx and that it’s currently not thread safe so it must run on the UI thread which means that for about 1:20 the application looks like it’s not doing anything. Very bad, very very bad! On top of that each time we change a value via slider on a single StadiumTeamData it takes about 6 seconds to finish calculating. Again blocking the UI thread. A very important detail to note is that when a single StadiumTeamData has an input value change only objects that depend on that StadiumTeamData and objects that depend on those object etc. are recalulated. This means that out of 12,240 StadiumTeamData instances only 1 is being recalculated and only 1 team, 1 division, 1 league, and the top level values of the formula model are being recalculated. We have been trying to improve PDFx performance for some time now, and we have a few more tricks up our sleeves, but most of the tricks are around load time not calculation time.

F#

After listening to a ton of .NET Rocks recently I’ve learned a lot about F#. I was so intrigued that I set out to create an F# implementation of the same formula model we created in C# and PDFx. The implementation took about 32 hours, but that’s also with a ton of research. By the end I think I could have written the entire thing in less than 16 hours which would be less time than the C# and PDFx implementation. I learned that functional programming lends itself to parallelization more than object oriented programming. Due to the fact that functional programming encourages an approach of not modifying values because everything is immutable by default the F# implementation can be run on a background thread as well. The cool part about all of this is the theory that many sub calculations can be run at the same time then aggregate the output to run a final answer calculation. Our current formula model is perfect for this approach. Because we no longer have a dependency on the PDFx to know when a property changes the PropertyChanged event is only raised once to trigger all calculations and is then only triggered once for each property that is updated by the output of the calculations so the UI will be able to respond. The object model takes a bit more than 1 second to load and the first calculation is done in another 2.5 seconds. The total load time is about 3.5 seconds. Compared to 79 seconds that’s 95% faster in F# just for load. Each subsequent calculation when a value changes via slider on a StadiumTeamData takes about 1.2 seconds. Compared to 6 seconds F# is about 80% faster for each calculation. Unlike the C# and PDFx implementation I have not optimized the F# formula model to only calculate the object tree that changed, instead all 12,240 StadiumTeamData instances are being recalculated each time and value changes in the entire object model. So we could still become more performant by only calculating the single StadiumTeamData that changed and the related team, division, league, and then the top level values of the formula model.

Results

A complete breakdown of my comparisons can be found in this excel file. I wanted to call out a few very important results in this post to wrap things up.

Readability

I used to think that C# and PDFx was very readable. And while it is for very simple models it can get unwieldy. F# however is the clear winner here. I reduced lines of code by the hundreds. I can see one entire formula in one file which is compact enough to fit on my screen at one time, versus C# and PDFx which takes up multiple files due to multiple classes, and it requires me to do a lot of scolling due to the amount of lines a single property takes up. This seriously increases maintainability.

Performance

When it comes to performance C# and PDFx were blown out of the water. Application load time was improved by 95% and calculation time was improved 80%. This is serious business here!

Time to Implement

This is a slightly skewed comparison due to experience. I was impressed by the fact that C# and PDFx took 16-24 hours and F#, a brand new language, took only 32 hours. I am convinced that I can write F# faster than C# using PDFx on future projects.

Next Steps

I will be diligently searching for opportunities to use F# in production client code. It is a no brainer to me. I agree with the statement from many of .NET Rocks podcast guests talking about F# and functional programming, “Every software engineer should learn F#!” It just makes sense!

Resources

Source Code: Formula Implementation Proving Ground

C# and PDFx Executable

F# Executable

Formula Excel Workbook

F# vs. C# Comparison Excel File

C# to F#: My Initial Experience and Reflections

When someone tells you, “You’re doin’ it wrong!” There is often a feeling to push back and get defensive. I’ve learned this is a worthless response. So when I was told that formulas should be written in F# not C# I took it to heart and decided to give F# and functional programming a whirl. While the jury is still out on performance, only because I haven’t completely finished my test app, F# has proven to be WAY more readable as far as formulas are concerned, and load time compared to my C# counter example is AWESOME! In this article I will discuss some high level comparisons and my approach so far.

Motivation

Here at InterKnowlogy we pride our selves on our ability to solve problems in the best way possible for our customers while still preserving readable, reusable, and elegant code. One problem that has come up over the last few years has been how to handle formulas. For example, if I have an Excel workbook with multiple sheets each with a set of complex formulas how do we transpose that workbook into code? My former co-worker and friend Kevin Stumpf in collaboration with the IK team developed what we call PDFx or the Property Dependency Framework. PDFx is a great succinct way to allow properties to depend on on properties by leveraging the INotifyPropertyChanged interface and a LINQ esque API. This was revolutionary for us. Instead of needing a completely separate formula calculator we could build our formulas directly into objects. We could create class for each sheet in an Excel workbook and have a property for each cell. This solution is elegant and easy to maintain. Features our previous implementations were not. This also allowed us the amazing capability to validate our formula output directly to cells in Excel. We have increased in productivity and the code is more reliable because of these things.

So what’s the problem? Performance! It’s not a matter of how complex the formula is, C# is lightning fast at math as far as we are concerned. However, each property that depends on another or more requires a property registration full of lambdas. Lambdas are slow, although you wouldn’t know it unless you were trying to call them about 2 Million times. With depth and width of our object model is really the problem here. Sheer number of instances each with N properties causes load time to be slow. Once loaded PDFx is awesome! Formulas run very quick and we have few grips about performance after load, but load time when accessing properties 2 Million times and running lambdas during that time can take about a minute.

Is there a better way? MAYBE! F# is our next attempt.

Why F# and Functional?

Honestly I’ve only started diligently listening to DotNetRocks in the last month. Shame on me I know. BUT! I backtracked some sessions on F# and Functional Programming. BEST… IDEA… EVER!!! I started looking into the capabilities of F# and feel strongly that I needed to get smart on the topic. We’ve been trying to optimize PDFx for some time now and have a few more tricks up our selves, but that doesn’t mean that it’s THE right way to do formulas. It’s certainly a really good one, but best? To be determined. Functional programming seems like a very intuitive way to handle formulas. After listening to how easy it is to parallelize work in F# I was sold. Functional programming forces you to think differently. Everything is immutable by default in F# and therefore the old ways in C# of looping and creating are over. This help preserve the integrity of your formulas and data which sounds great. Plus, would be no need for property registrations or lambdas and therefore load time, in theory, would only be bottlenecked by instantiating C# objects from the database. The question is runtime performance, which is still to be determined.

Approach – C# vs. F# Formula Comparison App

Since PDFx is open source we wanted to find a way to show it off in all it’s glory. We created a sample formula model in Excel and implemented it in C# using PDFx. The effort to create the workbook took longer than the 2 days it took me to implement the software solution. With this example we have been able to recreate the performance conditions that one of our clients has. Which is really great news! Because this means it is the perfect sample to implement in F# to see if it is more performant than it’s C# cousin. So far F# has taken me a longer period of time to implement, but only because it’s a new language. In fact, I already feel confident that I would be WAY faster in F# than in C# when dealing with formulas like this sample. I’m really excited to see the final results and of course the sample app and Excel workbook will be released as proving points. So look forward to more on this subject.

One major difference about using F# vs. C# & PDfx is that PDFx allows the formula model and the UI model to be the same. In F# this is not true. You need separation between your formula model, which is really the formula inputs and functions, and the UI model. For F# the UI model in our sample app has two mechanisms: GetFormulaInputs(), and ApplyFormulaOutputs(). The F# formula model has 2 main calculations that are called easily from C# with the inputs provided by GetFormulaInputs(). The F# formula model spits out outputs which are then applied in C# via the ApplyFormulaOutputs() method. I’m very close to have this working, but wanted to get my initial thoughts out on the matter first.

Stay Tuned

I’ve been super impressed with F# so far and the community using it. I haven’t struggled too terribly yet, but getting into a functional thought process and thinking in F#, a totally new language to me, has been tough. I have high hopes for the possibilities. The F# Language Reference has become my new best friend!

DevLink – Crawl, Walk, Talk: Windows Phone 8 App Lifecycle and Speech API

Huge thanks to all who attended my session. It was a blast! I hope you found it helpful and informative. You may find my Presentation Deck, Code, and a recording of the session below. Feel free to ask me any questions or give me any feedback you’d like in the comments below.

Session Description

Many Windows Phone apps in the store are good, but they could be great if they understood the very basics of app Lifecycle management. App users should never know they left the app due to app behavior. We’ll discuss and learn how to effectively and efficiently suspend, tombstone, resume and restore Windows Phone apps. Then we’ll move on to teaching our apps how to respond to Voice Commands. Voice Commands are one of the most helpful features and yet one of the least leveraged features in the Windows Phone platform. We’ll learn where they can help and how they can streamline the user experience.

Material Links

Contact InterKnowlogy

If you’re interested in receiving our News Letter please email: curious@interknowlogy.com

If you’re interested in career opportunities please email your resume: findyourcalling@interknowlogy.com

If you’re interested in partnering with us please email: curious@interknowlogy.com

DevLink – Master Windows 8 Location and Proximity Capabilities

What a great session! Thank you to everyone who attended. I enjoyed preparing the materials for this session and I hope you found it helpful and informative. You may find my Presentation Deck, Code, and a recording of the session below. Feel free to ask me any questions or give me any feedback you’d like in the comments below.

Session Description

The age old punch line “Location, Location, Location” is all too applicable in technology now-a-days. Come learn to leverage Windows 8’s Location API, one of the most important features in the mobile computing world. We’ll cover how to help users locate themselves as well as helping them track their next Ski trip. Proximity is another vital part of many great apps today. Join us to learn to leverage NFC tags and connect to peers through wireless communication. After mastering the Location and Proximity capabilities you’ll be able to create high value Windows Store Apps.

Material Links

Contact InterKnowlogy

If you’re interested in receiving our News Letter please email: curious@interknowlogy.com

If you’re interested in career opportunities please email your resume: findyourcalling@interknowlogy.com

If you’re interested in partnering with us please email: curious@interknowlogy.com

Session 12 of the WinRT Development Class – Hackathon Results and Prize Giveaways (Links to All Class Materials & Recordings)

WinRTWebBannerSmall_JPEG

THAT WAS AWESOME!!! We had some killer apps show up to this and I just wanted to say thanks to everyone who showed attended any of our classes. I am very pleased at how well everyone performed. We had some rough patches, but I’d say this class was a huge success! I’d love to hear what you thought about it! What can we do to improve it?

Special Thanks

First a huge thanks to Kim Schmidt who, despite many struggles during the course of this class, has been an outstanding support. She secured our location and really got this class up and running. So again, a huge thanks to her! Also, vNext_OC has been critical in this event. We want to thank all those who have helped organize the user group and keep it running! Great job! We want to give a special thanks to our hosts Saddleback College. They were tremendous hosts and helped us a ton! And a huge thanks to Microsoft for sponsoring dinner each night. It was delicious! Of course we wouldn’t be anywhere with out our prizes so another giant thanks to Microsoft and Nokia DVLUP who sponsored all of the cool prizes and giveaways! Kevin and I have feel honored and privileged to have worked with such amazing sponsors, leaders, and attendees! Thank you everyone for your participation!

WP_20130520_008

Overview Of Sessions

Blog Post Links (posts contain links to recorded sessions 2-11):

Development Environment for Windows 8

Session 1 & 2 of the WinRT Development Class – Introduction, XAML, and WinRT’s Control Framework

Session 3 of the WinRT Development Class – App Lifecycle and Navigation

Session 4 of the WinRT Development Class – Async/Await, WinRT API, and Security

Session 5 of the WinRT Development Class – Search and Settings

Session 6 of the WinRT Development Class – Share Contract

WinRT Development Class – Spring Break Update

Session 7 of the WinRT Development Class – Live Tiles and Background Tasks

Session 8 of the WinRT Development Class – Orientation And Near Field Communication

Session 9 of the WinRT Development Class – Intro to Model-View-ViewModel (MVVM)

Session 10 of the WinRT Development Class – InterKnowlogy’s WinRT MVVM Framework Part I/II

Session 11 of the WinRT Development Class – InterKnowlogy’s WinRT MVVM Framework Part II/II

MeetUp Links:

1. Introductory Lecture (Nov 27th by Danny & Kevin)
2. Introduction to XAML and WinRT’s powerful Control Framework; (Dec 4th by Danny & Kevin Click here for the video recording)
3. Page-Navigation Model and Application Lifecycle (Jan 8th by Danny Click here for the video recording)
4. Fundamentals (Async/Await, WinRT API, Security) (Jan 15th by Kevin Click here for the video recording)
5. Settings and Search Contract (Jan 28th by Danny Click here for the video recording)
6. Share Contract (Feb 4th by Kevin Click here for the video recording)
7. Live Tiles and Background Tasks (March 18th by Kevin Click here for the video recording)
8. Orientation Handling and Proximity using Near Field Communication (NFC) (March 25th by Danny Click here for the video recording)
9. Introduction to ModelViewViewModel (MVVM) (April 8th by Danny Click here for the video recording)
10. InterKnowlogy’s WinRT MVVM Framework Session Part I/II(April 22nd by Kevin Click here for the video recording)
11. InterKnowlogy’s WinRT MVVM Framework Session Part II/II(May 6th by Danny Click here for the video recording)
12. Presentation of Hackathon Results + Certificate/Prize Giveaway(May 20th by Danny and Kevin)

Session 11 of the WinRT Development Class – InterKnowlogy’s WinRT MVVM Framework Part II/II

WinRTWebBannerSmall_JPEG_thumb[1]

That’s a wrap! All code sessions are now complete! Awesome! Now to see the Hackathon results!

Session Resources

Overview Of Sessions

The links below lead you to Meetup Events where you can RSVP. We look forward to seeing you at our next session!

1. Introductory Lecture (Nov 27th by Danny & Kevin)
2. Introduction to XAML and WinRT’s powerful Control Framework; (Dec 4th by Danny & Kevin Click here for the video recording)
3. Page-Navigation Model and Application Lifecycle (Jan 8th by Danny Click here for the video recording)
4. Fundamentals (Async/Await, WinRT API, Security) (Jan 15th by Kevin Click here for the video recording)
5. Settings and Search Contract (Jan 28th by Danny Click here for the video recording)
6. Share Contract (Feb 4th by Kevin Click here for the video recording)
7. Live Tiles and Background Tasks (March 18th by Kevin Click here for the video recording)
8. Orientation Handling and Proximity using Near Field Communication (NFC) (March 25th by Danny Click here for the video recording)
9. Introduction to ModelViewViewModel (MVVM) (April 8th by Danny Click here for the video recording)
10. InterKnowlogy’s WinRT MVVM Framework Session Part I/II(April 22nd by Kevin Click here for the video recording)
11. InterKnowlogy’s WinRT MVVM Framework Session Part II/II(May 6th by Danny Click here for the video recording)
12. Presentation of Hackathon Results + Certificate/Prize Giveaway(May 20th by Danny and Kevin)

Nokia – San Diego Windows Phone 8 Hackathon – May 2013

The San Diego Windows Phone 8 Hackathon held at Nokia on May 11th 2013 was a huge success! I want to express my sincere appreciation and respect to all who participated. We had 33 Windows Phone 8 Apps submitted after a mere 4 hours of development time. That’s quite an impressive feat, especially considering the quality of the apps that were presented! I hope everyone that participated will put the finishing touches on their apps and submit them to the Windows Phone Store. (And let me know!)

I took a new approach to presenting code topics at this event and I am quite pleased how it turned out. We held 3 sessions each 1 hour long. Between each session was 1 hour for hands on lab. In the past I’ve shown different codebases for my presentation vs. any hands on labs. At this event I decided to try to use the same codebase for both. This meant I could show off a working version of the hands on labs before attendees would start them. This gave the attendees greater understanding about what they were about to do and how the code topics work in an app setting instead of some simplified, non-best practices sample. This worked tremendously well. I received many comments from attendees about how much they loved seeing the code first then writing the code themselves, and how that was much more effective than seeing two different samples. The apps shown off during the hackathon were evidence to me that my approach was effective and good.

This event was not my first; however it was my first with 111 attendees! It was also my first as a Nokia Developer Champion. I had a blast and the atmosphere and enthusiasm of attendees told me that everyone else did too. I look forward to the many follow up sessions we discussed during the event and other events coming up in the future!

Link to event materials: NokiaWP8May2013

Session 9 of the WinRT Development Class – Intro to Model-View-ViewModel (MVVM)

WinRTWebBanner_JPEG

This class was really made possible by all those who attended. And a special thanks to Tom Hannum for lending me your power cord. We all learned a lot at this session. I hope everyone will go review the presentation video and get familiar with MVVM. If you have any questions leave a comment below! Happy Coding!

Session Resources

Overview of Sessions

The links below lead you to Meetup Events where you can RSVP. We look forward to seeing you at our next session!

1. Introductory Lecture (Nov 27th by Danny & Kevin)
2. Introduction to XAML and WinRT’s powerful Control Framework; (Dec 4th by Danny & Kevin Click here for the video recording)
3. Page-Navigation Model and Application Lifecycle (Jan 8th by Danny Click here for the video recording)
4. Fundamentals (Async/Await, WinRT API, Security) (Jan 15th by Kevin Click here for the video recording)
5. Settings and Search Contract (Jan 28th by Danny Click here for the video recording)
6. Share Contract (Feb 4th by Kevin Click here for the video recording)
7. Live Tiles and Background Tasks (March 18th by Kevin Click here for the video recording)
8. Orientation Handling and Proximity using Near Field Communication (NFC) (March 25th by Danny Click here for the video recording)
9. Introduction to ModelViewViewModel (MVVM) (April 8th by Danny Click here for the video recording)
10. InterKnowlogy’s WinRT MVVM Framework Session Part I/II(April 22nd by Kevin)
11. InterKnowlogy’s WinRT MVVM Framework Session Part II/II(May 6th by Danny)
12. Presentation of Hackathon Results + Certificate/Prize Giveaway(May 20th by Danny and Kevin)

Session 8 of the WinRT Development Class – Orientation And Near Field Communication

WinRTWebBanner_JPEG

Now that you’re all oriented and able to communicate in close quarters I want to see some rockin’ apps! Thanks again for attending! And for those that didn’t make it, you missed an AWESOME magic trick! My best yet.

Session Resources

Overview of Sessions

The links below lead you to Meetup Events where you can RSVP. We look forward to seeing you at our next session!

1. Introductory Lecture (Nov 27th by Danny & Kevin)
2. Introduction to XAML and WinRT’s powerful Control Framework; (Dec 4th by Danny & Kevin Click here for the video recording)
3. Page-Navigation Model and Application Lifecycle (Jan 8th by Danny Click here for the video recording)
4. Fundamentals (Async/Await, WinRT API, Security) (Jan 15th by Kevin Click here for the video recording)
5. Settings and Search Contract (Jan 28th by Danny Click here for the video recording)
6. Share Contract (Feb 4th by Kevin Click here for the video recording)
7. Live Tiles and Background Tasks (March 18th by Kevin Click here for the video recording)
8. Orientation Handling and Proximity using Near Field Communication (NFC) (March 25th by Danny Click here for the video recording)
9. Introduction to ModelViewViewModel (MVVM) (April 8th by Danny)
10. InterKnowlogy’s WinRT MVVM Framework Session Part I/II(April 22nd by Kevin)
11. InterKnowlogy’s WinRT MVVM Framework Session Part II/II(May 6th by Danny)
12. Presentation of Hackathon Results + Certificate/Prize Giveaway(May 20th by Danny and Kevin)

LionHeart & World Autism Awareness Day 2013

LargePC

Today holds a special place in my heart. For the last 3 years my wife has been working with children with Autism helping them to overcome and manage behaviors that are reactive, inappropriate, and distracting to themselves and others. Her kids are amazing little creatures! While some are severely impacted many are not. They are so sweet and love making her get well cards when she is out. It’s impressive. Certainly I can never hope to achieve such satisfaction in my job as a software engineer. However, I can definitely try to help!

Introducing LionHeart: Autism Behavior Interventionist Assistant

It is with great pleasure that I bring you LionHeart; a proof of concept aid for Behavior Interventionists delivering services to people with Autism. The concept of LionHeart came from my wife while we were discussing ways software could help influence medicine. She explained that her job as an Interventionist consists of going home to home to visit each child for a few hours. During the session she uses ABA therapy to help the child learn appropriate behaviors. First the Interventionist reviews notes from the previous session. Then during the session the Behavior Interventionist will keep tally of behaviors and responses. After the session the Interventionist records qualitative notes in the child’s record binder. Every month the binder is collected and paper records are read and transferred to different paper records. It’s a very tedious job. The binder is then hopefully returned to the child’s home before their next session. If not, the Interventionist will have little to no idea how that child is progressing and how to proceed. Even with the binder, there is no easy way to see the child’s improvement over time in a specific program without reading weeks of session notes. Because it is so difficult to see progress over time it is rarely if ever done in the field.

LionHeart is the solution. The app provides a hint at what digital records could look like. It also gives an idea of how easy it would be to generate reports in the office let alone in the field. The concept is that each Interventionist would have a device, like a smart phone or tablet, that would have an app like LionHeart installed. The app has the ability to track behavioral data, record session notes, review client progress, map client addresses, help keep Interventionists in the know about cancelled/postponed/rescheduled sessions, and more! What is currently an extremely inefficient system could be streamlined to benefit the client as well as the service provider.

Goal of LionHeart

My goal when I set out to create LionHeart was to show that technology can be used in simple ways to accomplish great things! My wife wishes she could use LionHeart in the work place, but that of course requires much more than a simple Demo app. I hope, in the near future, that Autism service providers will strive to adopt time saving and quality of care improving technology such as LionHeart. InterKnowlogy is a wealth of knowledge and I continue to be impressed by how well our team works to effectively deliver awesome and amazing software. I would love to see InterKnowlogy partner with Autism service providers to make LionHeart a reality!

Why the Name LionHeart?

The name itself is a fun little story. I had been contemplating a name for a few days for the project. The thought came to me that these kids have huge hearts. They are just so full of love. And while this thought ran through my head I was staring at a pad of paper my mother in-law had given me with a print of a lion on it. I realized lions have big hearts and these kids are often as wild as a lion. How fitting then to give the app the title of LionHeart representing both the challenges and rewards for working with children with Autism.

Screen Shots

List of Session & Viewing Session Info

1a_SessionList2_Session

List of Session Notes & List of Programs in a Session’s Notes

1c_SessionNotesList3b_SessionNotes_Programs

Client Information & Client Progress Over Time

4a_Client_Info4b_Client_Progress

Special Thanks

I would have never finished LionHeart with out the awesome support of the InterKnowlogy team and our RECESS time. You can learn about RECESS here. A special shout out to Beth Juncal who help me work with a designer to make the app beautiful. A huge thanks to Xen Rabara who came to InterKnowlogy in January as a fresh graduate from my alma mater Neumont University, and styled almost the entire app! Travis Schilling also helped me get in a crucial last minute revision to help with usability! Of course I want to thank the company Holly works for, C.A.S.E. Inc., and especially her boss, Cynthia Norall, who has helped me understand the challenges faced by Interventionists in the field. And finally my wife Holly who continues to impress me everyday in her care and love for children with Autism!

Development History

If you’re a developer interested in learning how to make a Windows Phone app like LionHeart check out this blog series on how LionHeart was created.