Co-op Highlights 13

With regard to website development at my organization, there’s been a term, MVC, that has surfaced several times recently.  It seems that this is something that they are working towards with their web application.  I thought I would do a little research about it as I have very little knowledge about MVC.

MVC stands for Model View Controller and has actually been around for a very long time, originally known as Thing-Model-View-Editor in 1979.  It seems that MVC is an architectural pattern which puts a web application in 3 different buckets:  Model, View, and Controller.

  • The Model represents the logical structure of data in the application, along with the classes and rules for how data is changed.
  • The View is the user interface (UI) – it requests information from the Model and generates an output representation to the user.
  • The Controller sends commands to the model which updates the model’s state – it also sends commands to an associated view which can change the view’s presentation of the model (output to the user).

If you have an existing web application, you can upgrade it by adding MVC (I believe this would be the case at my work, as we have an existing web application and would want to transform it to an MVC platform).  I found this website (http://www.hanselman.com/blog/IntegratingASPNETMVC3IntoExistingUpgradedASPNET4WebFormsApplications.aspx) which is Scott Hanselman’s blog.  Scott Hanselman is also one of the authors of the Professional ASP.NET 4 book, a book I am using in another class this semester.  This particular post from January 2011 addresses the exact question – how to add MVC to an existing website.

This article seems to indicate that you could create a default ASP.NET MVC application as a reference tool and then use something like Beyond Compare (at http://scootersoftware.com/) to compare your current web application and the reference ASP.NET MVC application to determine the differences.  You then would have an option to copy over missing files or folders into your current web application project.

The article is pretty simple and straightforward – it almost seems too easy, so I’m curious if there is a lot more to this integration.  There seems to be some difference between converting a ‘website’ to incorporate MVC and converting a ‘web application’ to incorporate MVC.  I believe Scott Hanselman’s article talks specifically about a web application.  I found another website (http://jefferytay.wordpress.com/2012/04/10/getting-asp-net-mvc-3-to-work-with-asp-net-website-project/) that gives a pretty easy-to-follow example about how to add MVC to a website.

The first step seems to be making sure that you have ASP.NET MVC 3 installed (I found information here on how to do this).

The big next step concerns modifying your web.config file.  This specifically adds to the file:

<compilation><assemblies> section

<add assembly=”System.Web.Abstractions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ /> 
<add assembly=”System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ /> 
<add assembly=”System.Web.Routing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35″ />

The third step in this process is modifying the global.asax file.  You would add:

<%@ Import Namespace=”System.Web.Mvc” %> 
<%@ Import Namespace=”System.Web.Routing” %>

Add the following after <script runat=”server”>

public void RegisterGlobalFilters(GlobalFilterCollection filters) 

filters.Add(new HandleErrorAttribute()); 
}

public static void RegisterRoutes(RouteCollection routes) 

routes.IgnoreRoute(“{resource}.axd/{*pathInfo}”);

routes.MapRoute(“Home”, 
“home/{action}/{id}”, 
new { controller = “Home”, action = “Index”, id = UrlParameter.Optional });}

add the following inside application_start

RegisterGlobalFilters(GlobalFilters.Filters); 
RegisterRoutes(RouteTable.Routes);

after the <%@ Application Language=”C#” %> section.

Creating the Controller is the fourth step in this conversion process.  As a website project, the compilation happens at runtime, so the controllers are created inside the App_Code folder, instead of creating the Controller folder.  All Controllers need to end with the suffix of ‘Controller.’

Lastly, you would test your site.  Another post in StackOverflow suggests transitioning your website to a web application and then adding the MVC functionality.

Another Stack Overflow comment seemed to indicate that Scott Hanselman has updated this transition piece with a NuGet package to make conversion easier.  The steps include installing MVC3 (w/NuGet), selecting Library Package Manager through the Tools menu in Visual Studio, changing the Default Project to your web forms project, and typing ‘Install-Package AddMvc3ToWebForms.  This seems to indicate that it will add all of the necessary dlls, javascript files, and web.config settings to your website.  This website (http://delradiesdev.blogspot.com/2011/08/adding-mvc-3-to-aspnet-web-site.html) talks about this transfer in further detail.

One thing that I am also very curious about is the ‘why’ behind a lot of this.  Why would I want to transition to MVC?  Why would I chose a website vs. a web application vs. a MVC web project?  I still haven’t figured out the answers to those questions, but may post on this again if I find out more information.

Co-op Highlights 10

This past week, I was able to sit in on a meeting regarding the planning of a mobile application for our organization.  This main goal of this app would be to enable leaders to take attendance at the small group or events.  There are 3 University of Cincinnati students working on this project and they are actually building 2 different applications, one is the mobile web application (like a mobile website) and the other is an Android application.  They are walking through the SDLC (Software Development Life Cycle) and presented the mock-up of screens to our group.  I wrote about the SDLC in week 7.

sdlc

The team is currently in the Design process and this meeting helped to clarify what our organization would like to see in the mobile application.  There were some good ideas presented that would give the end user a better experience.  This included making the app not time out for at least 30 minutes, adding some help information (such as the phone number for Facilities, the building and room of the event, and normal building hours), and adding a second level page that would allow you to click on someone and have their contact information pull up on the screen.  In addition, the phone number and email would be ‘linked’ so that you could easily call a person.

Mark, our database expert and long-time contractor, suggested some additional tweaks to the design.  In the event that we would like to allow other similar organizations to use this app in the future, it would need to be changed to fit the look of the organization, also called skin.  The colors, logo, and name of organization should be able to be easily changed.

In addition, I just registered for my last semester of classes, which will start in January 2014.  I should be applying for graduation sometime in the next month and looking forward to April 2014 graduation.  Woo-hoo!

One of those Spring 2014 semester classes is my Capstone, a project-based class.  I have talked about possible projects with one of the folks in our IT department.  There is a real need for a good reporting tool that my organization could use.  We have great data in our database, but not a great way to retrieve that data (and slice & dice it any which way).  One suggestion was to look for an open-source reporting software that could be used and then write the code to connect it with our database.  There are several categories of work here – research reporting tools (Reportico was suggested by Mark, our database expert and long-time contractor), SWOT analysis, write code to make connections to database, testing, and training other staff.

This seems like a valid project, but I need to get approval from the Capstone instructor before moving forward with it.  I’ll keep you posted.  🙂

Web Applications vs. Mobile Websites

As a continuation from Co-op Highlights 6, I wanted to explore the differences between web applications and mobile websites a little further.  Previous to the Database Architect meeting last week, I had a pretty vague understanding of ‘apps’ and mobile websites.  So, I did a little research on the two.

I found 2 great articles about the differences and pros and cons of both web applications and mobile websites.  I’m sure there are 1,000 more articles out there, but these 2 seemed pretty straightforward.

Article 1 – http://www.hswsolutions.com/services/mobile-web-development/mobile-website-vs-apps/

Article 2 – http://www.adaptistration.com/blog/2013/04/30/understanding-the-difference-between-apps-and-mobile-websites-2013/

Here’s what I found:

Web applications and mobile websites are both accessed by a handheld device, most commonly a smartphone (iPhone, Android, or Blackberry), but also tablets.

A mobile website would be very similar to your organization’s website, complete with HTML pages and links between those pages.  These would be accessed over the Internet (for smartphones, this could also be accessed through a data connection like 3G or 4G networks).  Obviously, because of the small screen size, your website would need some modifications to make it user-friendly for a smartphones.  A touch-screen interface is also a consideration when compared with a typical mouse-click on a full-size website.  Mobile websites can contain text content, data, images, and even video.  Another feature would be a click-to-call option or location-based mapping.

One example would be a person who pulls up your mobile website for your organization and wants to call the organization for more information.  With the click-to-call feature, there is no ‘write down the phone number and then call’ type action.  Location-based mapping could use GPS to pick up the location of the person accessing the mobile website and then display the location (maybe a pizza place or the nearest store) based the person’s location.  Pretty handy.

Web applications, or apps as they are commonly known, are a little different.  An app is an application (a module or object, to use different, but similar words) that is downloaded and installed on your handheld device (smartphone or tablet) instead of being accessed through a web browser.  An app could contain similar information to a mobile website (contact information, location information, general text describing your organization, etc), but it could also contain the ability to track certain pieces of information (maybe calories eaten, steps walked, etc) or it could be a way for the organization to push (send would be another word) information to the end-user.  Interactivity is a consideration, as the web application could allow paths for two-way communication between the end-user and the organization.

Both articles that I read indicated that a mobile website would be a first option or step, while an app would be something possibly added later for a specific purpose.

Mobile Websites

There are a number of benefits to consider with a mobile website.  Some of these pros include:

  • Broad access – instantly accessible using a web browser (while an app needs to be downloaded and installed first)
  • Compatibility – a mobile website can be accessed by many different handheld devices without worrying about developing different versions for different types of devices (the big example is iPhones vs. Androids)
  • Upgrading Content – mobile websites can be updated easily and the new information would be immediately available to the end-user (while an app would need to have an update downloaded and possibly re-installed for the new information to become available)
  • Cost-effectiveness – mobile websites are less costly, both in terms of time and money, to develop and maintain; developing and supporting a web app is much more expensive (considering developing for multiple platforms [iPhone, Android, Blackberry], upgrades, testing, compatibility, etc)
  • Shareability – mobile websites can be shared easily between people, just be sending the URL link in a text message or email (an app cannot be shared in this way)
  • Findability – mobile websites can be easily found because their pages would be displayed in search results (for example – search for the nearest pizza place) while apps are typically found via the app stores.  Another benefit to using a mobile website is that it is available whenever the user requests it, while an app may only be useful to the user for a short period of time.  I’m thinking of the Global Leadership Summit app from the August 2013 Willow Creek conference.  People attending the conference were encouraged to download the app to find additional information about the speakers, order resources, and complete surveys during the conference.  Once the conference finished, there is not really a compelling reason to keep the app on your smartphone.

Web Applications (Apps)

There are some instances when developing a web application (or app) makes sense.  And, maybe, an app for your organization only focuses on one part of the organization (such as a budget tool), instead of trying to represent your entire organization.  Web applications would be most efficient for providing interactivity or gaming, regular personalized usage, complex calculations or reporting (possibly financial, banking, investments), or if you needed to provide offline access to content (no network or wireless connection required).

Additional benefits to developing web applications include the fact that apps use programming code native to the platform and can result in higher performance.  There is also a name/brand recognition associated with the app that could increase distribution (‘it’s an Android app’), and apps can utilize some of the native functionality of a smartphone, such as the camera and gyroscope.  Apps can be an ideal solution if you need to deliver specific content to a specific audience. 

Web Application, Mobile Website, OR Responsive Mobile Website

There is a third option!  A Responsive Mobile Website takes the best of typical mobile websites and integrates the responsiveness

A responsive mobile website acts the same regardless of what device is used, so just one platform is required and is less expensive overall to develop and maintain.  It is searchable to anyone through  a web browser and can be easily shared with others.  There are no manual updates; content is updated and visible the next time a user accesses the mobile website.  Responsive mobile websites can be developed with database-driven capabilities, so that specific content is available to the user based on membership, preferences, or location.

There are a couple of drawbacks to this responsive design, including not being able to access a smartphone’s native functionality (like the camera and gyroscope) and not being able to connect your app with the status or reputation of a third party app distributor (name/brand recognition for Android or iPhone).

Consumers have also displayed a preference for mobile website interfaces for things such as shopping and searching.

Conclusions

At first glance, there appeared to be just 2 choices, web applications or mobile websites.  However, a third option surfaced and seems to be a hybrid of the two – the responsive mobile website.  Considering your goals is an important consideration here.  If your organization wants to share information with a broad audience or enhance your marketing efforts, a mobile website is a good choice.  If your goals are primarily interactivity, complex calculations, or offline content, then an application may be the way to go.

However, if you’d like to provide your audience with robust content that is easy to access and easy to share, regardless of the type of device, and can be tailored to a user’s preferences or membership level, then a Responsive Mobile Website may be the best solution.

Co-op Highlights 1

Last week, I sat in on a meeting discussing ‘Planting the Vine.’  The ‘Vine’ is a database and web application that was developed over many years at my work.  It tracks just about everything related to clients here at my work:  client data, group and activity history, volunteer roles and activity, event planning, attendance, donations, online registration, etc.  Maybe 6 months ago, a couple of volunteers here came to the IT department with a great idea (and one that we internally had already been beginning to consider).  What if we packaged the Vine in a way that could be delivered to other similar, but smaller organizations (that maybe didn’t have enough resources on their own to create something like this)?  There have been many meetings over the last 6 months and this meeting last week was the most recent.

It seems that there is always going to be a management/administration side and a technical/development side on projects.  The 3 volunteers that originally approached our IT department are developers, some self-employed, and definitely leaning more into the technical side of things.

Our IT department represents the management/administration side (as I see it currently).  Things like a business plan (this endeavor may require a 501(c)(3) organization to be set up), cost analysis, pricing, approving further developments, approving modifications, and making presentations or recommendations to interested organizations fall in this camp.

One of the things I have been thinking about this week is the balance between management and administration and the technical and programming worlds.  Technical experts need to understand the basics of management, cost-benefit studies, and articulating ideas and plans to upper management (who ultimately approves funding for projects), while management and administration experts need to understand the basics of the technical side – time & labor requirements for coding, coding logic, caching options, hosting options and costs, testing requirements, and different methodologies for development.