Friday, 10 November 2017

Building a Bot for Sport Accessibility

Earlier this year I had the opportunity to help a local non-profit sports organization (NPO) get information on sport disability and accessibility out to athletes, teachers, parents, coaches and sport leaders.  I was fortunate enough to work with some great experts from the NPO as well as Microsoft.  After some initial discussions we came to the conclusion that we would go with a natural language interface otherwise known as a bot.  We decided on using Microsoft’s Bot Framework and at least one Microsoft Cognitive Service, the Language Understanding Intelligent Service (LUIS).  This blog will be about some of the decision making that went into choosing these technologies instead of others and what benefits were gained by our choices.

Chat or Click

When we first sat down with viaSport British Columbia, the NPO to discuss their needs, they made it very clear they wanted something different.  There have been plenty of attempts in the past to provide information to their constituents and there were examples of other organizations, such as the Canadian Paralympic Committee, that have provided some of the information. 

One of the methods used in the past was to have a series of cascading combo boxes where you selected some property which would then set a selection list for the next combo drop down box.  You would work your way through these items until you came to the end.  One of the problems with this is it assumes a certain level of knowledge of what question you want answered.  You also have no flexibility in decisions made during the process.  To continue you must select something even when “your” option wasn’t available.  viaSport (our NPO) wanted something a bit more friendly and more in line with the way its members commonly communicated with each other.  Sending messages and typing on their phone or computer using natural language seemed to be a natural (pun unintended) fit.  We decided on chat instead of click and implement a chat bot using the Microsoft Bot Framework and natural language with LUIS and Microsoft Cognitive Services.  Later on, we added the use of some other cognitive services.

Getting Started

The initial goal was to simply allow their constituents to visit their web site and ask, in plain language, for information specified by sport, disability and person asking for the information.  For example, a coach might ask “How do I coach swimming to a paraplegic” and the goal would be to provide reference material helping that coach to provide guidance to the athlete specified.  To accomplish that goal we needed only two elements and a hosting service.  The Microsoft Bot Framework could nicely handle the conversation part of things (back and forth), with a C# code behind, doing the lookup of the information and Microsoft’s LUIS Cognitive Service to provide the natural language understanding of the questions being asked. 

Ultimately the thing that would make the project a success, as with most projects, is the quality of the data or information we could provide to the the clients.  The whole point of the exercise was to provide curated information to the people who needed it without the massive amounts of information you would get from a Google or Bing search.  So, combined with our bot and natural language processing we used Microsoft Azure SQL database to store the curated list of information and a Microsoft Azure App Service.  Setting of all Cognitive Services is done through Azure also, so signing up, initially, for the free trial let us move forward with a prototype almost immediately.

Starting Coding is Fun!

I chose C# as the language of choice for a couple of reasons.  I could have done the bot project in NodeJS but chose not to.  First is that I’m very familiar with C#.  I’ve written hundreds of applications using C# and it seemed the logical place to start.  Also, I realized very early that not only did I have to create the Bot but an administrative tool for viaSport to manage their curated links and content.  That tool would be best written in C# as a UWP app.

AppService-BotServiceSo, to begin we used a template provided by Visual Studio 2015.  It created a very simple template that didn’t include anything to do with LUIS and required that all the connectivity to LUIS had to be done by me.  The good news is, since we created our bot, there now an easier way.  Inside Azure, you can simply create a new “AI + Cognitive Service” service and one of the choices is “Bot Service (Preview)”.  This creates the whole framework for you to begin, including all the hooks you need into LUIS.  It’s like magic!

BotTemplateOnce you create the Bot Service you are given a choice of 5 (currently) different templates for the bot using two different languages, C# or NodeJS.  The templates cover everything from a simple “echo bot” where it just echo’s back the text input to a Q&A type bot to a bot using Azure Functions to the one we want, a bot template that will automatically bake in Language Understanding (LUIS).  Having that template would have been very helpful in the early days of creating this bot.  Once you have chosen your template the template wizard will walk you through all the options you need to create that bot including assigning the App Id (needed for publishing) and password (take note of all the ids and passwords, you won’t be able to get them later).  Once you have created the App, it will provision the LUIS service for you and you will be ready to start defining intents (basically an intent is what the natural language will be interpreted as, for example “How to Coach”). 

BotService_EditCodeAll the starter code with all the keys already in place will be created for you.  You can easily hit the road running.  The Bot Service even provides an on-line editor that looks a lot like Visual Studio or you can download the source and use it with Visual Studio 2017 (even the free community edition) or lastly, have it uploaded to a source control provider like Visual Studio Team Services or GitHub.  You could literally deploy the Bot code as is and start using it (once you put some intents in).  The on-line editor is surprisingly useful and lets you get going right away.  You can even run and test your bot or debug it using the Bot Framework Emulator (they give you a link to download and install the emulator).

The End of the Beginning

At this point we had our prototype.  The next steps I’ll outline in a later blog involved building the back end database containing the content and an administrative tool for managing that content.  My goal was to hand off the project to viaSport without them needing to call me for every little thing.  I didn’t want to be a dependency for them moving forward.  I made myself available to help out but most of what they wanted to do they could easily do on their own, including manage the content, track usage and other telemetry and make improvements to the bot understanding, all without having any developers on staff or needing to contract one.

As I work through the building of this application over the next few blog entries, we’ll look into Windows UWP App development, other Cognitive Services, inclusivity considerations and telemetry. 

Tuesday, 17 October 2017

After Ignite–Bots and Brains Meetup–Part 1

What is a Community Meetup at Ignite

This year, in September I attended Microsoft Ignite in Orlando Florida for the first time in many years (since the days of TechEd actually) and for the first ever as a speaker.  I was deeply honoured to be selected as a speaker and even more so that I was selected for what is a relatively new format, the Community Meetup format.

I took my role seriously and spent a good amount of time preparing for this unusual presentation format.  Typically at these sorts of events the presenter gets up at the front of the room with a projector, some PowerPoint slides and perhaps a copy of Visual Studio to show some code.  At a community meetup presentation the participation shifts a bit to the attendees.  To get the most out of the session, attendees have to find the subject interesting, have some opinions and be willing to share those opinions.

As the community meetup host my role was to present the ideas and concepts to the attendees backed with my expertise and experience in the field and hopefully my comfort in facilitating discussion.  Our session (for it was both my and the attendees session) was BRK2388 “Bots and Brains: The Microsoft Bot Framework and Cognitive Services, better together”.  The idea was to discuss the difficulties with making a chat bot application that was responsive to the needs of people using it.  This included three main topics, frustration, inclusive design and deciding if a chat bot was even the best delivery mechanism for the application.

Our room held only 85 people and I’m happy to say we filled the room.  However, I do regret that perhaps hundreds were turned away at the door as our room and format dictated a much smaller attendance than were registered for the session.  I will continue to work with Microsoft to improve the format as I feel that the format presented a number of valuable benefits to attendees that they might not get in other more traditional passive sessions.  I believe that attending a well run community meetup should offer a great chance to network with other people interested in the same topic.  It offers the chance to come up with some possible solutions or considerations to problems that many of us face on a regular basis and perhaps just as importantly give a chance to be actively involved in the Ignite conference as opposed to the typical passive nature of attending presentations.

This is the room I spoke in.  Seats 85 people.  350 showed up.










Getting Started

So… what did we do?  We had a room of 85 enthusiastic attendees that came ready to participate.  We had ten tables of 6 people each with additional chairs around the perimeter.  We began by getting everybody to introduce themselves at their particular table.  My plan was to get each table to work together as a team.

Next we introduced everybody to a shared OneNote notebook that would provide all the attendees a place to take notes that we would make available after the conference.  Each table would hopefully record notes of discussions and ideas right in the shared OneNote notebook (It turns out that they did… enthusiastically, more on that content in Part 2)

Now it came down to me where I introduced the topic we wished to discuss and more specifically what questions we would be addressing as a community.  I began by introducing my background in the Microsoft Bot Framework and Cognitive Services, my expertise in application development and some examples of  Bot/AI projects I have worked on.  Then we got to the meat of the meeting.  In a chat bot, how do you deal with Bot Frustration?  How do you make a chat bot that includes everybody and lastly how do you decide if a chat bot is the right solution in the first place.

When we got started with the first topic I was surprised to see everybody at each table actively participating in the table discussion and even more surprised that those sitting along the walls formed ad-hoc discussion groups without a table and began working on ideas.  There did not seem to be anybody I noticed that was left out of the discussion.  That made me feel pretty good.

What Could have been Better

I wish, in some ways that the session had been recorded for others to enjoy some of the feedback but it might not have presented well as a recording as there were 5-8 minute gaps of discussion where nothing obvious was happening to a recorded session.   I also wish that we could have accommodated the many people who were not permitted entry to the session due to seating availability. 

The difficult balance was between a community feel where everybody could participate and having so many people in the room that it becomes difficult to let everyone’s voice be heard.  We could easily have had a much bigger room available to a lot more people, but at what cost?  This is one of the challenges we will need to address for next year.  The fact that the meetup sessions were so popular was gratifying, concerning and encouraging, all at the same time.

I wonder if the elevated stage was more of a barrier to the presenter, me.  I spent a lot of time walking among the tables, listening to the discussions, offering some suggestions and advice and eliciting feedback from various tables and having to climb up to a podium separated me from the groups perhaps too much.

What Worked

The table discussion format actually exceeded my expectations.  Before the session I really didn’t know if what I had planned would work, would be fun and would provide valuable information to the attendees.  I thought it would (else why would I do it?) but it was satisfying to see that it worked out even better than expected.

We ended up with a whole bunch of information collected in the OneNote notebook on all three topics.  Some tables came up with some interesting names for their “team” (Revolving Table, Wall, Table Unique, etc…) and people seemed to have fun.  At the end of each 8 minute period of discussion we had two or three tables present their ideas using hand-help microphones we had available.  There were some great ideas (Part 2).

The size of the room was great for discussion purposes and Microsoft really spent quite a bit of time thinking of how this session format would work to reflect the community meetup feel.  We were, I think, the only room that had it’s own permanent snack station for attendees.  We had a Microsoft Surface Hub provided for which I used it to host the OneNote notebook so we could see progress being made and we had great technical support in the room at all times.

Part 2 –  The Results

After Ignite–Bots and Brains Meetup–Part 2, the Results

So, we have discussed what exactly a Community Meetup session at Microsoft Ignite is in Part 1.  Please feel free to have a read through to see what we did and how we did it.  This entry is to discuss the results of that session at Ignite.  During the session multiple groups of people came up with some great talking points on the three main topics covered concerning the Microsoft Bot Framework and Cognitive Services.  We discussed what I thought were three of the main points in creating bots using the Microsoft Bot Framework.  The three topics were, for the most part, focused around how Microsoft Cognitive Services could help.  We discussed user frustration when using bots, what were and were not problems that could be solved with a bot application and lastly how to make bots more inclusive to all people.

We had 10 tables of 6 people and, at least for the first topic, we had recorded responses from twelve distinct teams including one of my favorites “the Wall” team which consisted of people who were sitting in chairs along the wall that banded together to make a discussion group.  Some people along the wall chose to join existing tables for discussion.  It was great!

Most of the information below is not necessarily my opinion but that of people attending the Microsoft Ignite Community Meetup BRK2388, Bots and Brains.

Bot Frustration

The premise of this section was threefold.  How do I prevent frustration?  How do I detect frustration? and how do I resolve frustration?  All three points should be important considerations when creating a chat bot interface to an application.  Before arriving in Orlando I had some pre-conceived notions of how to detect frustration.  It was interesting how many different options the group came up with that I had not thought of.

With regards to detecting frustration there were plenty of suggestions.  Microsoft Cognitive Services provides a service called the Text Analytics API that lets you detect in a range of 0 to 100% very negative or very positive sentiment.  Another team suggested using the Language Understanding Intelligent Service or LUIS to detect curse words indicating frustration.  Outside of sentiment and curse words, suggestions were made to look for repeated questions and entities (parameters) indicating frustration at not getting a correct answer.  Overall if we consider the three main ideas above I believe we can be fairly competent at detecting most forms of frustration.

Before frustration ever happens, there are things we can do to prevent it from starting.  One group suggested using training data based on past feedback to ask leading questions to help get more accurate answers.  Some of the suggestions were beautiful in their simplicity.  For example provide the option to see a tutorial as we did for a project I worked on called the Accessibility Sport Hub or ASH.  The tutorial nicely sets expectations and suggestions on getting the most out of the bot.  It also outlines what the bot can, and just as importantly cannot do.  One of the responses seems to apply to this category as well as what to do to resolve frustration after it has occurred.  Hand the conversation off to a real person.  In the case of prevention, as soon as the bot can detect that it may not be able to resolve the inquiry, have a method of handing off the inquiry to a real person.  The bot can be the method of collecting information and a real person is used to resolve the problem that might not be addressable by the bot.

Lastly what do we do when things go badly and we have a frustrated or even angry person using our bot.  The most often repeated solution here is recognizing when human intervention is required and hand off the bot to a qualified individual for resolution.  Another suggestion by one of the “Wall” groups was to provide additional options or help when frustration is encountered.  Perhaps they don’t know what the bot is capable of and providing them the option of learning what is available might help.  Improving the feedback to the user was also suggested and this can also fall under the heading of prevention. 

Humour is something else that can be introduced.  Giving the bot a bit of a personality can help build a friendly relationship and perhaps reduce stress levels.  One caveat to consider is sometimes humour is not universal and one should be cautious that you don’t introduce more problems than you create.  One of the most popular suggestions was to use the “panic button” method of providing a way to ask for help while in the middle of the conversation.  If you provide an escape or some way to get back to the start and/or get help it might alleviate some of the frustration being created.

Bot Solutions

What makes a good bot solution?  It’s a question that isn’t asked often enough in development.  “What is the best way to do this” rather than “I know how I can do this”.  So we asked the community meetup what they thought.  It was interesting what considerations they came up with when trying to decide what sorts of applications would be best as chat bots.

One of the more interesting considerations is the target age group of the app.  As strange as it may seem different generations of people approach how they communicate in different ways.  The other one that was interesting was globalization and how bots might be better at dealing with multiple languages than many other solutions. 

Once we got past demographics there were suggestions that a solution that might require a more specific answer faster than searching Bing or Google might find a directed bot conversation more useful.  Also the ability to handle difficulties interactively would be helpful.  A bot would be useful at connecting people to internal data repositories like information on employment, HR and general inquiries would be ideal for a bot. 

Under the “not so useful” category, several tables/groups suggested that an “advice” type application might not be so useful as pure chat bots.  For example, providing legal or medical advice might have moral and legal barriers where the repercussions of providing improper or incorrect information are significant.  For example, we probably don’t want bots handling 911 calls at this time. Although, a hybrid solution where a bot collects basic information and then hands off the session to a human might be reasonable in some cases.

Lots of groups felt that bots are not very helpful for very complex needs.  For bots to work, somebody has to write code for the responses and depending on whether or not the path people using the bot need to follow has many branches or not could affect the effectiveness of the bot.

Inclusive Bots

This category turned out to be a bit more difficult than the others.  In many ways people feel it’s difficult to relate to the issues at hand.  However, once you consider that building an inclusive bot is not about building a bot for specific people but, instead, for all people, you can start to see ways to help in that area.  Including everybody does not mean just disabilities but also, culture, language, gender and a whole host of other variables that make people unique.

One of the items that came up is voice.  Microsoft nicely announced at Build 2017 the ability for a bot to be available as a Cortana skill basically enabling speech to text and text to speech handling so your bot doesn’t require keyboard or mouse input.  That’s a huge leap forward in usability and inclusivity.  Other items discussed were using Cognitive Services like the Computer Vision API to discern the age of a user. 

Also using images in providing information might help work around language barriers (although the Bot Framework does support many language, it might not cover all of them).  Addressing gender differences were also mentioned and here vision can help too by detecting gender using the Computer Vision API.

To Wrap it Up

Privacy was not mentioned and I think we always need to be aware of people’s privacy.  When we use various Cognitive Services we should always make sure we have permission where necessary to provide people with the choice.

Overall, it was quite remarkable how many different opinions and ideas came out of our room of just 85 people.  Everybody stayed right to the end to make sure they got their voice heard.  The OneNote notebook is available to those that attended my session and you can view it too if you wish.  Also, join the conversation at at the Microsoft Tech Community!

I hope that everybody got something out the session.  Maybe met a like minded person, found some information from myself or others in the room that might help in decision making over bots and AI or just generally enjoyed the break from the traditional session.  I thank all the attendees and hope that I have the opportunity to do it again next year.

Wednesday, 19 October 2016

Talking about Bots – Setting it up

Have you thought about using the Microsoft Bot Framework?  I have!  If you’ve ever wondered, I’m going to try and give you a hand up by pointing you in the right direction.  Maybe give you a few tips along the way and help clarify a few things along the path.

Getting Started

connector-getstarted-create-projectYour first step is to install the Bot Framework Template into your Visual Studio (I’m assuming you have Visual Studio installed already).  I guess the first step is to decide what language you are going to build in.  Because I am a Windows Platform sort of guy, I’m going to use C#, if you are too then it will make this a lot easier to follow along.  You can find the “Getting Started” page with the links at https://docs.botframework.com/en-us/csharp/builder/sdkreference/gettingstarted.html but you can directly download the template from here.  When you look at the getting started document, it does give you most of what you need to get going but ultimately you are going to have to connect a few dots and turn on a few lightbulbs on to get to where you want to go.  Once you have downloaded the template and created your first project, come back here for next steps (not in the above doc)

Creating Your Bot App

Your next step requires you to create a Bot in the Bot Framework.  You are going to have to modify a couple of things in your just created Bot Framework app in Visual Studio based on what you do here.  First, go to http://dev.botframework.com.  You will need to have a Microsoft Id to successful complete this next task.  Click on “Register a bot” to get started.  Don’t worry if you don’t know everything, you can fake it a little bit until you do some other stuff later.  You need to know your bot name and bot handle.  You can makeup stuff here.  You will need to create a BotWebConfigMicrosoft App ID and password, but they nicely give you a button you can press to do that.  Make a note of the App ID and password because you’ll need those in the Web.config file of your bot application.  For the publisher profile, you can fill in most of the URLs with placeholders, but you will need to provide those before going live in any way.  In your Web.config, put the id and password as you see in this picture.  There are security issues with putting ids and passwords in your Web.config but for just playing around locally on your system, its not a problem and security is not part of this post.

Testing Your Bot Locally

Bot EmulatorYou need to install the Microsoft Bot Framework Channel Emulator.  It won’t look as pretty but it will let you see what is going on.  Once you have installed this little emulator, go ahead and start the app in Visual Studio.  This should launch a browser (you can choose which one), make note of the port # in the URL that is loaded.  Now open the emulator and change the “Bot Url” to match the port number above.  Don’t change anything else.  Lastly, paste in the App Id and App Password and you should be good to go.
In Visual Studio, open the “MessagesController.cs” file and put a breakpoint on line 22 (inside the “Post” method.  Now go back to the emulator and Type “Hello” into the message space and hit enter.  You can now step through how the bot responds to the question (it just parrots back what you said with a char count).  Now you can start seriously thinking about what smarts you want to add to your bot using whatever AI you can think of.

Ready for More?

Now that you have a (somewhat) stupid bot, what do you do?  Well, you’ll need to deploy it to an Azure App Service or some other web site if you want the public to get access to it.  You’ll also need to add some brains to it.  Like what happens when somebody says hello.  You know, add a little personality to the game.  More on that in future blogs.

Monday, 17 October 2016

Developer Life Saving 101: Survival Training with Visual Studio Team Service

As discussed in a previous post, disaster can strike at anytime.  Most companies think about things such as protecting documents, insurance for property, fire safety procedures, and other physical protections.  But what do you do about software assets.  Does your company create software?  Even non-software companies often create software.  In-house IT departments will often have utilities and other little bits of code that are really useful in keeping a company operating smoothly and most employees and executives of the company may not even know its being used. 

When Disaster Strikes

My company develops software for ourselves (Windows Store) and for our customers.  Microsoft’s partner program is flexible enough for not only larger Fortune 500 companies to partner with them but also small software consulting firms like ours and everybody can win.  One of the great features of the partner program for us is our Microsoft Action Pack Subscription that provides us countless benefits but the one I want to focus on today is the Visual Studio Team Services (VSTS) account.

Let me go back a bit in time to October 2013 when a fire broke out in the same city block as our office.  The fire was devastating, wiping out half of a city block with buildings dating back as far as 1909.  I was told by some of the firefighters that the temperature at the heart of the blaze was almost 2,700 degrees (does it really matter if it’s Celsius or Fahrenheit?) and steel light poles across the street were melted. Our building, housing our primary offices, were just one building and a good strong wind away from being destroyed.  There was nothing we could do about it at the time… There was, however, something we could do in advance and we did it, have you?

Peace of Mind and Better Software

GitFirst and foremost, as stated previously, was the fact that our vast investment in software development was 100% protected in VSTS, either in Git or Team Foundation Version Control.  A lot of our legacy software was developed using Visual SourceSafe (VSS) which was migrated to Team Foundation Server (TFS) (on-premise) and then up into the cloud with Team Foundation Version Control (TFVC). If you have any combination of Source Control that uses VSS or TFS then migration is pretty painless.  We did it in a day (for four developers).  However, newer product development is now taking advantage of Microsoft’s implementation of Git source control.  Did you know you can run both simultaneously? Git provides a robust team environment for development, when implemented properly and with reasonable processes adhered to by developers. 

Of course, just storing your source code in the cloud isn’t going to get you better software.  It might save your existing software or allow your development team to work remotely should inconveniences occur like a power outage at the office or hardware failure for some reason, but you need tools to help with your process to really make gains in quality that go beyond just hiring great developers.

In my opinion the two best features that improved our software quality and the speed of software delivery are the integrated Testing Tools and Continuous Integration.  Of course, there are lots of other great features including Agile Tools, integrated DevOps and lots more. 

Test, Test and Test Again

testQuality starts at the beginning and begins with the developer.  However, how do you know that your software is solid.  One of the things we teach is to develop unit and UX testing at the same time as the actual software development.  No commits without at least a corresponding unit test being included, which sometimes takes quite a bit of willpower.  That’s great for the developer testing his stuff but how do you know the quality of a commit into your system.  Easy, with VSTS I setup my commit process to force a rerun of all tests when a commit is made on a branch before a Pull Request can be created to merge that branch into the parent.  This essentially puts a double check in place that the code created was of high quality.  Of course, this is dependent on the developers creating the tests in the first place, so test creating must become part of your culture of development.  If I’m creating websites, I can also implement load testing.  Having those tests run in VSTS is just one part of Continuous Integration (CI) that you really want to investigate thoroughly.

Round and Round We Go

VSTSContinuous Integration is part of combination of a whole host of tools available to the developer and to the process of software delivery.  You can have build agents in the cloud automatically build your application with new commits.  Results are provided in an extensive report that tells you if anything went wrong, what work items are included and any code changes and test results you may have.

I had the opportunity to work with some students on a team project.  The Continuous Integration allowed the team to commit bug fixes and new features without worrying about breaking the master build.  No Pull Requests into the dev or master branch were permitted without a new build being completed successfully.  CI did the work automatically.  Nobody had to “remember” to get it done.  On top of the build, CI also executed and reported on all the tests in the software so full regression testing of every committed bit of code was done.

Once all the tests were passed and a Pull Request was completed into the dev branch, CI automatically published the app for our dev team to try out and then when it was rolled to the “staging” branch it rolled out to our customer for review, again automatically, providing very fast turnaround for updates.

We have a pulse

This has all been a great benefit of our partnership with Microsoft.  We are able to deliver higher quality software with less work.  Continuous Integration along with writing and adding tests to our solutions as we go has created an environment where we can deliver great software.  Moreover, with cloud based source control all integrated together we are relatively well inoculated against disaster or just annoying inconvenience.

Tuesday, 11 October 2016

Pick a Platform, any Platform – The Prestige

The last stage of any magic trick is “The Prestige”.  In illusionist terms it means we make the rabbit reappear after making it disappear, or the tiger or the lovely assistant.  In our case we are going to take use Visual Studio to do more than just create an app or application for the Windows Platform.  We are going to do so much more.  We will take an existing Windows Phone 8.0 Silverlight app and convert it into a Xamarin App allowing us to publish not only a UWP app but also an Android one and an iOS app.  I must admit I don’t know where I’ll go with this as I have not tried this before.  What follows is what I did, how I did it, and where I messed up (fingers crossed).

Part 1: The Pledge

Part 2: The Turn

Create a new Application

SquarePegWP80Rather than take my existing project and try to change it, it made a lot more sense to start with a brand new Xamarin App and layer in the code.  To do this, I opened the old WP8.0 app in Visual Studio then opened a new instance of Visual Studio for my masterpiece.  To make my life simpler and to reduce the amount of the learning curve I’m going to start with a Xamarin Forms app.  This relieves me of the need to learn pretty much anything about Android and Apple UX development.  You may need to install the Xamarin Development AddXamarinToVS2015Tools (They are typically not installed by default in VS2015).  If you use Windows 10, right click on the Start button and select “Programs and Features”.  Find Visual Studio 2015 and click “Change”.  Scroll down until you find “Cross Platform Mobile Development” and check the “C#/.NET Xamarin” one and click “Next”.  This will get you the tools you need.  You need a bit of disk space to make it happen and it will take a bit of time to install but it’s very easy to do.

To create a new Xamarin Forms application

  1. NewProjectopen Visual Studio 2015
  2. click “New Project” in the start page
  3. Expand Templates/Visual C# and Click “Cross-Platform”
  4. Select “Blank App (Xamarin.Forms Shared)” and Click OK

If you choose to create the UI part of your app in Native, simply select the (Native Portable/Shared) project templates.  For our purposes though we want to keep it as generic as possible with a single UI across all platforms so we will used Portable.

Making Our App

I’m not going to go too deep into this part of the process at this time.  There are some basic things you need to know about Xamarin Forms though.  First, always remember that Xamarin Forms are NOT UWP XAML in the traditional sense.  You need to substitute the new Xamarin Forms control for something you might use in UWP XAML.  For example instead of <TextBlock/> you might use <Label/>.  The properties will be subtly different too.  Instead of a Foreground property in Label you need to use the TextColor.

These small changes could be frustrating in the beginning but most things you do in XAML you can do in Xamarin Forms and the big win is that when the app is compiled for the various platforms the Xamarin Forms controls will be compiled into their equivalent native controls for that format.  So, you end up with native apps for all the platforms but only had to create one UI.  This is a big win in my mind.

To get in-depth knowledge on Xamarin Forms controls and just about everything else you can think of to do with Xamarin.Forms, download a free copy of Charles Petzold’s book “Creating Mobile Apps with Xamarin.Forms”.

SetImageAnother gotcha I encountered was with images.  When binding or trying to reference images, you have to be very conscious of the different platforms and resolutions.  Furthermore, you need to put the images you will be using in each of the platform projects rather than the shared/portable project included.  Each platform has it’s idiosyncrasies and you need to account for those.  The Xamarin web site for developers very nicely describes the issues with images.   The code is fairly simple once you know.

One other item that I missed was that Radio Buttons are not a “thing” on all platforms.  You need to think of something else if you truly want this to be cross platform.  You COULD do it but then would not look “native” on at least one of the platforms.  I used a <Picker/> for my home page.  Below is what it looks like in UWP.  Please refrain from design commentary.  I didn’t do much of that here.  This is strictly a move from plain Windows Phone 8.0 to Xamarin UWP/iOS/Android and it turned out ok.

homepage

More to come

While this concludes the magic trick, it by no means is the end.  I plan on completing this app and testing on iOS and Android.  To this point, everything I’ve done works on all three major platforms.  I still have to build the game play and the “Help” pages.  I now know that it’s not as simple as copy and paste but far easier than a complete rewrite.  I, at least, have the framework of what and where everything should go.  I know which controls work and which do not.  I know what WP80 control translates to what Xamarin.Forms control.  The rest is a walk in the park.

Tuesday, 4 October 2016

Pick a Platform, any Platform – The Turn

Continuing on from our initial foray into creating an analogy between magic and development as outlined in our previous blog on “The Pledge”, in this post we want to cover the first part of the real magic.  We’ve already established (I hope) that Visual Studio is a great, maybe even the best, tool for developers.  We know we can write code fairly easily and create software of all different shapes and sizes for the Windows Platform.  But what about the magic?  For those of us old school developers who started in Visual Basic before it was even part of Visual Studio or even newer developers that see “Visual Studio” and only think “Software for Microsoft Windows” today’s post is for you.  We want to roll up our sleeves, show you that we have nothing under there and describe a little magic with Visual Studio.

Part 1 – The Pledge

Part 3 – The Prestige

The Turn

So, if you will watch my hands (at no time will my fingers leave my hands) you will see that using just Visual Studio I can now create, deploy and debug apps on Windows (no surprise there) and Android.  With a little help I can now create, deploy and debug apps on iOS and macOS as well.  With just a few magic words (written in the mystical language of C#) you can do it too!

Xamarin

The magic wand is Xamarin.  It is the tool that allows us to create multi-platform apps all with Visual Studio on a Windows device.  You aren’t creating some sort of HTML app that runs on all the platform, you are creating native apps with native user interfaces for all the platforms.  You have lots of ways you can create the magic too so the show should never get boring.  For the most part there is little to nothing else you need except in the case of iOS.  For that you need to have a macOS device of some sort (MacBook or MacMini will work) to do the compile.  However, it’s important to note that although the Mac is sitting there doing it’s job you are still writing the software, testing and debugging right on your Windows device, even for iOS…
The first thing you need to do is make sure you have Visual Studio 2015 installed.  Any edition will do.  The next step is to install Xamarin.  Another great thing is you can get started on this for nothing.  You can combine Visual Studio community edition with Xamarin and they are both free.

Platforms

With Xamarin you develop in multiple ways depending on your preference and needs.  A good majority of any code you might write is re-usable across all the platforms.  And you can write it all in C#.  In fact, in most instances you will find that doing the code in C# is easier than Objective-C, Swift and Java.  Things like Asynchronous programming are just easier with C#’s built in language level support.  Inside Visual Studio you can do your code behind using C# but still creating your UI using storyboards for iOS and XML for your Java and of course XAML for Windows.  Or, you can use Xamarin Forms and really bump up your re-usable code.  I attended a workshop a short while ago where we built an app in the space of a couple of hours using Xamarin Forms with a little help from James Montemagno, Principal Program Manger at Xamarin/Microsoft. Xamarin Forms uses XAML to design the UX but when you build the app for the different platform Xamarin translates all that work into native controls and apps so you don’t have a layered common generic app but rather an actual Native app with access to Native APIs.

My Breakthrough

I have written a lot of apps for the Windows Platform.  At last count it was over 80 apps.  But I have never written an iOS or Android app.  Being a .NET developer I just didn’t have the time to get up to speed on those platforms and still maintain my edge in .NET.  Xamarin destroys that wall and lets me look at my existing apps in a new light.  There is now no need for me to make that decision.  I can take existing apps and with a minimal amount of work prepare them for distribution on iOS and Android.  To me that is the real magic.  I have played around with XCode and Objective-C but to get the quality I expected was just not easy.  This removes that barrier and lets me move forward. 

Next Up – The Prestige

Now that we have shown Visual Studio to be both “normal” and magical I need to make the assistance re-appear, the Rabbit to disappear.  I need to conclude the magic trick.  To do that I’m going to take one of my existing apps written for Windows Phone 8.1 and move it to UWP/iOS/Android and document the experience.  Hold tight for the Prestige.  I’ll try to keep the language not too offensive and will hopefully help you experience the magic too!