An  App  for  High-­‐Productivity  Note  Taking  in  Meetings  

Third  Year  Project  Report    

The University of Manchester School of Computer Science

 Author:  

Hasan  Sener  Kolcu    

Supervisor:  Suzanne  Embury  

 May  2015  

                                       

 

 

Abstract    The  aim  of  this  project  is  to  produce  a  tablet  application  to  help  academic  staff  with  taking  and  managing  notes.  The  application  is  to  be  used  by  persons  from  all  different  areas  of  academia:  students,  researchers,  supervisors  and  others.  The  application  allows  them  to  take,  manage  and  share  notes,  amongst  other  pieces  of  functionality  that  aim  to  make  the  note-­‐taking  process  automated  and  easier  for  users  to  manage  all  aspects  of  note-­‐taking.    The  scope  of  the  project  involves  learning  mobile/iOS  development  and  applying  it,  successfully  completing  an  iOS  application  ready  for  deployment  on  iPhone/iPad  devices.  The  finished  application  is  evaluated  through  various  methods,  and  the  feedback  is  noted  for  use  in  future  endeavors.    The  software  and  architecture  choices  for  this  project  have  been  justified,  as  well  as  the  programming  techniques  used,  such  as  the  agile  methodology.  These  are  expanded  on  throughout  the  report.                                                                    

 

 

Acknowledgements    I  would  like  to  thank  my  supervisor,  Suzanne  Embury,  for  her  continuing  support  and  advice  throughout  the  duration  of  the  project.    I  would  also  like  to  thank  my  friends  Abdulrahman,  Ayoub,  Mohamad  and  Mohamed  for  their  continuous  moral  support  throughout  my  university  life.  I  am  proud  to  call  them  my  brothers.    Finally,  a  massive  ‘I  love  you’  from  the  bottom  of  my  heart  to  my  mum,  my  mum  and  my  mum  again.  I  would  not  be  where  I  am  without  my  father  and  I  would  not  be  the  person  I  became  without  my  siblings,  Zeynep,  Huseyin  and  Gulsum.  

                           

   

Table  of  contents    

Abstract  ............................................................................................................................  2  

Acknowledgements  ...........................................................................................................  3  

Table  of  contents  ...............................................................................................................  4  

Chapter  1  ..........................................................................................................................  6  

Introduction  ......................................................................................................................  6  1.1   Background  ....................................................................................................................  6  1.1.1   Meetings  ........................................................................................................................  6  1.1.2   Problems  .......................................................................................................................  6  1.1.3   Existing  Solutions  ...........................................................................................................  7  1.1.3.1   Evernote  ....................................................................................................................  7  1.1.3.2   OneNote  ....................................................................................................................  7  1.1.3.3  Google  Docs  ....................................................................................................................  8  1.2  The  Project  ...........................................................................................................................  8  1.2.1  Project  Motivation  .............................................................................................................  9  1.2.2  Project  Glossary  .................................................................................................................  9  1.3  Project  Goals  ........................................................................................................................  9  

Chapter  2  ........................................................................................................................  10  

Development  ..................................................................................................................  10  2.3   Platform  Choice  ...........................................................................................................  13  2.4   Application  Architecture  ..............................................................................................  16  2.6   Flattening  the  Data  Structure  .......................................................................................  20  2.7   Application  Design  .......................................................................................................  22  2.7.1   User  Interface  Design  ...................................................................................................  22  2.7.2   Technical  Design  ..........................................................................................................  24  

Chapter  3  ........................................................................................................................  26  

Implementation  ..............................................................................................................  26  3.1   Implementing  the  Application  ......................................................................................  26  3.1.2   Firebase  integration  .....................................................................................................  30  3.1.2.1   Integration  ...............................................................................................................  30  3.1.2.3   Issues  to  Overcome  ..................................................................................................  30  3.1.2.4   Remaining  Issues  .....................................................................................................  31  3.2   Approach  .....................................................................................................................  31  3.2.1   Prioritising  functionality  ...............................................................................................  31  3.2.2   Test  Driven  Development  .............................................................................................  31  3.3   Database  Structure  ......................................................................................................  32  

Chapter  4  ........................................................................................................................  32  

Results  ............................................................................................................................  32  

4.1   The  Log-­‐in  Module  .......................................................................................................  32  4.2   Note  Taking  Module  ....................................................................................................  33  4.3   Contacts  Module  ..........................................................................................................  35  4.4   Incomplete  Functionality  .............................................................................................  36  

Chapter  5  ........................................................................................................................  36  

Testing  and  Evaluation  ....................................................................................................  36  5.1   Testing  .........................................................................................................................  36  5.1.1   Test  Driven  Development  .............................................................................................  36  5.1.2   Unit  Testing  .................................................................................................................  36  5.1.3   Testing  Overview  .........................................................................................................  37  5.2   User  Evaluation  ............................................................................................................  37  5.3  Developer  Evaluation  .........................................................................................................  38  

Chapter  6  ........................................................................................................................  38  

Conclusion  and  Future  Work  ...........................................................................................  38  6.1   Reviewing  Original  Objectives  ......................................................................................  38  6.2   Personal  Development  .................................................................................................  39  6.3   Future  work  .................................................................................................................  40  

References  ......................................................................................................................  41  

Appendix  A  ......................................................................................................................  44  

Evaluation  Questionnaire  for  the  iOS  Application  ............................................................  44                                                      

   

 

Chapter  1  

Introduction    The  purpose  of  this  chapter  is  to  give  the  reader  background  information  about  the  place  note  taking  holds  in  the  life  of  an  academic,  the  traditional  methodologies  of  taking  notes  and  the  problems  associated  with  these  approaches.  Existing  solutions  to  the  described  problems  are  identified,  analysed,  and  explained  whilst  highlighting  the  gaps  in  these  solutions  that  do  not  cater  to  the  user’s  core  requirements,  rendering  these  solutions  unsuitable  for  use  in  the  problem  domain.  After  covering  the  nature  of  the  problem,  the  chapter  gives  a  brief  overview  of  the  project,  describing  its  motivations  and  key  features.  

1.1 Background

With  the  intention  of  making  the  motivations  behind  the  project  clear  to  the  reader,  this  sections  aims  to  give  background  information  about  an  academic’s  meeting  driven  lifestyle.  

1.1.1 Meetings

The  nature  of  academia  not  only  requires  but  demands  a  high  level  of  organization.  Working  on  multiple  projects,  liaising  with  persons  of  varying  expertise  from  students,  to  professors,  to  external  bodies,  an  academic  has  to  keep  on  top  of  all  matters  across  all  of  their  concerning  fields.  Over  the  course  of  say,  a  research  project,  progression  needs  to  be  tracked,  milestones  need  to  be  marked,  and  accomplishments  need  to  be  credited.  This  creates  the  need  for  a  system  through  which  we  can  go  to  one,  easily  accessible,  mutually  up  to  date,  place  through  which  all  of  this  can  be  monitored.  

1.1.2 Problems Throughout  this  journey,  an  academic  is  typically  faced  with  multiple,  consecutive  meetings,  day  after  day,  week  after  week.  Having  little  to  no  time  for  lunch  breaks  let  alone  bathroom  breaks.  This  journey  is  typically  documented  through  the  use  of  physical  notes  with  the  never  failing  pen  and  paper,  categorised  into  specific  sections,  within  specific  folders,  stored  on  specific  shelves  within  the  office.    

Many  researchers  stay  within  the  same  field  for  a  good  number  of  years,  in  most  cases  not  moving  offices.  This  can  be  noticed  from  the  accumulation  of  substantial  amount  of  notes  which  is  reflected  by  the  number  of  folders  on  shelves,  leading  to  notes  being  dispersed  all  

over  the  office,  always  creating  some  confusion  when  it  comes  to  the  start  of  a  new  meeting.    

The  struggle  doesn’t  stop  here,  keeping  track  of  the  decisions  that  are  made  in  these  meetings  is  a  massive  issue;  having  them  written  on  a  piece  of  paper,  in  a  folder,  on  a  shelf  somewhere  doesn’t  really  provide  any  functionality  in  terms  of  keeping  up  to  date  with  the  statuses  of  decisions  or  action  points,  nor  does  it  give  us  an  overall  progress  report  or  does  it  provide  an  infrastructure  for  alerting  people  of  tasks.  

It  is  clear  to  both  the  academic  and  an  external  observer,  that  something  needs  to  change.  

1.1.3 Existing Solutions Even  though  there  are  many  solutions  that  exist  in  the  current  tablet  market  that  try  to  address  the  aforementioned  problems,  none  of  them  are  tailored  specifically  for  use  in  academia,  rather  they  are  more  general  purpose  applications  that  target  a  broader  market,  trying  to  encapsulate  as  many  customers  as  possible.  This  section  will  describe  existing  technologies  that  have  been  researched,  tried  and  tested  and  continue  to  illustrate  the  gap  in  the  market  for  academic  note  taking.  

1.1.3.1 Evernote Evernote  is  a  multi-­‐platform  note  taking  system  which  supports  a  wide  variety  of  platforms,  ranging  from  iOS  for  iPhones  and  iPads  to  Android,  Windows  Phone  and  Web,  with  support  even  for  PCs  on  both  Mac  and  Windows.[30]  

 For  the  setting  of  a  meeting,  tablets  are  most  appropriate,  so  in  my  research  of  this  piece  of  software,  I  focused  on  the  iOS  version  through  the  iPad.  Evernote  provides  an  eloquent  way  of  organising  notes  in  the  form  of  ‘notebooks’[1]  which  is  very  similar  to  storing  notes  in  physical  folders,  separating  the  notes  by  category  and  purpose.  Checklists  can  be  created  and  notes  can  be  shared  with  peers.  Although  checklists  do  indirectly  provide  a  way  to  check  progress  they  do  not  allow  for  action  to  be  delegated  to  individuals  whilst  seamlessly  making  alerting  them  through  the  system.  Additionally,  although  sharing  of  notes  may  be  required  in  certain  places  it  is  not  always  desirable  to  share  notes  in  their  entirety  as  there  isn’t  always  a  need  for  complete  transparency  with  all  involved  parties.  

1.1.3.2 OneNote Similar  to  Evernote,  Microsoft’s  OneNote  is  available  on  a  wide  variety  of  platforms,  but  for  continuity  we  will  focus  here  on  their  iOS  version  of  the  application.  [31]  

 OneNote  provides  a  slightly  different  method  of  organising  notes,  through  the  introduction  of  sections  in  addition  to  having  notebooks.  This  is  very  useful  for  a  continual  

documentation  where  everything  is  still  relevant  each  time  that  the  notes  are  accessed,  however  this  is  not  the  case  with  academic  meetings,  where  we  usually  are  only  interested  in  the  latest,  most  recent  updates  and  notes  on  previous  meetings  become  a  distraction  more  than  anything  when  it  comes  to  viewing  then  notes  again.  

 To-­‐do  lists  are  incorporated  into  the  notes  and  can  also  be  created  as  a  lone  entity,  however  they  lack  integration  into  the  meeting  mindset,  in  which  certain  to-­‐do  items  should  be  shared  with  certain  people.    Notebooks  can  be  shared  with  peers  but  again,  this  gives  rise  to  the  issue  of  ‘all  or  nothing’  sharing  which  is  undesirable  under  the  circumstances  we  are  in.  

1.1.3.3 Google Docs Google  Docs  is  accessible  on  all  platforms  and  provides  amazing  collaborative  document  creation.  With  its  primary  objective  being  collaboration,  Google  Docs  has  the  underlying  infrastructure  to  automatically  save  all  work  in  real  time,  providing  an  extensive  history  through  which  rollback  to  earlier  versions  of  a  document  is  made  possible.  With  support  for  offline  access  as  well,  note  taking  is  taken  to  a  completely  new  level.  [32]  

Documents  can  be  grouped  in  a  folder  like  manner  and  can  provide  access  restriction.  This  does  not  however  create  easy  access  as  we  are  still  required  to  navigate  through  the  entirety  of  our  collection  in  order  to  access  the  correct  document.  

In  short,  Google  Docs  does  not  provide  the  main  functionality  that  is  required  to  take  notes  in  academic  meetings,  as  there  is  no  explicit  functionality  that  is  tailored  to  keeping  track  of  decisions  within  meetings.    

1.1.4  Other  Solutions  

All  of  the  solutions  mentioned  above  in  addition  to  a  few  other  applications  were  used  and  tested  by  the  client  with  none  of  them  providing  a  tailored  solution  for  the  problems  faced.  It  is  following  this  that  the  client  reverted  to  documenting  meetings  on  hardcopies  which  continuously  prove  to  be  difficult  to  manage.    It  is  after  this  research  into  current  applications  in  this  area  that  it  was  found  that  none  of  the  current  existing  solutions  fully  covered  the  problem  domain.  Most  existing  systems  tend  to  focus  purely  on  the  documenting  aspect  of  taking  notes  during  meetings,  whilst  overlooking  the  interactive  integration  needed  to  provide  seamless  management  of  meetings.  For  this  reason  it  was  decided  that  a  tablet  based  application  would  be  best  suited  for  the  client  as  it  provides  the  facilities  and  resources  that  are  required  to  provide  an  efficient  solution  within  this  problem  domain.      

1.2 The Project

This  section  aims  to  give  the  reader  an  overview  of  the  project  that  this  report  will  describe  in  detail.  The  motivations  behind  the  project,  key  features,  and  glossary  are  all  included  in  this  section  so  that  proceeding  chapters  are  clearer  to  the  reader.  

1.2.1 Project Motivation It  is  clear  from  the  research  of  existing  technologies  that  there  is  a  need  for  a  productive  note  taking  system  that  is  tailored  to  the  needs  of  academics.  Existing  solutions  provide  a  wide  range  of  functionality  but  do  not  explicitly  cater  for  needs  such  as  having  an  integrated,  distributed  set  of  action  point’s  in  which  each  item  can  be  specified  an  assignee.  Nothing  exists  that  allows  us  to  view  the  progress  of  a  group  of  meetings,  or  get  updates  from  other  users  regarding  progress.  These  gaps  in  existing  systems  formed  the  starting  point  for  this  project  which  aimed  to  create  a  tablet  based  application  that  provided  seamless  entry  and  organisation  of  notes,  a  rapid  action  point  entry  system,  and  a  progress  view  for  meetings.  

1.2.2 Project Glossary Term   Description  

Table  1.1:  Project  Glossary  

1.3 Project Goals The  main  objectives  of  the  project  is  to  create  an  application  that  is  suitable  for  use  by  academics  on  both  ends;  those  leading  the  meetings,  and  also  those  who  attend.  This  must  be  reflected  in  the  design  of  the  system  so  that  different  types  of  users  have  different  privileges.  It  is  of  the  upmost  importance  that  real  value  is  produced  and  delivered  as  a  means  of  driving  the  project  and  is  essential  to  develop  a  deeper  understand  of  the  mobile  application  development  process.  

Action  Point   a  specific  proposal  for  an  action  to  be  taken,  typically  one  arising  from  a  meeting.  The  action  point  may  be  undertaken  by  one  or  multiple  persons.  

Assignee   the  person(s)  who  are  responsible  for  the  completion  of  an  Action  Point  

Assigner   the  person  who  has  delegated  an  Action  Point  to  an  Assignee  Meeting   a  sitting  that  consists  of  a  number  of  participants  gathered  to  discuss  

a  specific  subject  matter  Deadline   the  latest  possible  timing  for  an  action  point  to  be  completed.  

Chair   the  person  who  is  leading  a  meeting.  

Minutes   a  summary  of  the  notes  that  were  taken  for  a  meeting,  with  key  points  such  as  action  points  highlighted.  

Segue   a  segue  defines  a  transition  between  two  view  controllers.  

The  whole  concept  of  mobile  development  in  general  and  iOS  development  in  specific  was  completely  alien  to  the  author  from  the  beginning  of  this  project,  therefore  a  lot  of  focus  and  time  has  been  exerted  into  learning  these  foreign  concepts.  This  was  another  core  objective  of  this  project  and  these  concepts  were  all  self  taught  through  various  different  resources.[26][27]    The  end  product  was  aimed  to  provide  an  efficient,  alternative  solution  to  the  problem  domain  and  was  intended  to  improve  the  meeting  experience  that  is  unique  to  academia.    

Chapter  2  

Development    This  chapter  describes  the  life  cycle  of  the  project  and  how  it  came  into  existence,  this  will  be  broken  down  into  four  phases:  design,  implementation,  testing  and  evaluation.  Each  of  these  phases  are  explained,  giving  an  insight  to  the  thought  process  behind  decisions  that  were  made  throughout  the  duration  of  this  project.      

2.1 Requirements Analysis  This  section  analyses  and  describes  the  requirements  gathering  phase  of  the  project.  The  requirements  gathering  process  was  conducted  by  initially  determining  stakeholders  and  the  contexts  in  which  they  would  interact  with  the  software,  followed  by  the  gathering  of  user  stories  which  allowed  the  author  to  derive  and  prioritise  the  requirements  of  the  project,  both  functional  and  non-­‐functional.  It  is  through  this  analysis  that  the  author  was  able  to  begin  designing  the  architecture  of  the  application.    

2.1.1 Stakeholder Analysis  Stakeholder  analysis  plays  a  key  role  when  it  comes  to  project  planning,  regardless  of  the  subject  area.  Crosby  defines  the  purpose  of  stakeholder  analysis  to  be  the  indicator  of  who’s  interests  should  be  taken  into  account  when  it  comes  to  decision  making.  With  this  in  mind,  we  need  to  vary  the  weighting  that  different  stakeholders  have  on  decisions.  This  requires  for  the  different  stakeholders  to  be  well  defined  and  distinct  from  each  other.    A  stakeholder  is  defined  as  “An  individual,  group,  or  organization  who  may  affect,  be  affected  by,  or  perceive  itself  to  be  affected  by  a  decision,  activity,  or  outcome  of  a  project.”[2]    We  can  categorise  stakeholders  into  three  groups[3][4]:  Primary  Stakeholders  –  These  are  users  of  the  system  who  are  affected  directly  by  the  system  through  interactions.  

Secondary  Stakeholders  –  These  can  be  people  or  groups  which  are  indirectly  affected  by  the  system.  An  interaction  that  a  primary  stakeholder  has  with  the  system  gives  cause  to  some  change  that  concerns  the  secondary  stakeholder.  

Key  Stakeholders  –  These  are  the  individuals  or  organisations  who  have  high  importance  within  the  project/system.  These  stakeholders  are  highly  influential  in  decision  making  and  steer  the  direction  of  a  project.  

It  is  important  that  we  identify  our  stakeholders  as  it  allows  for  varied  perspectives  on  proposed  solutions,  gets  more  ideas  on  the  table  to  be  assessed  and  delivered  on,  and  also  increases  the  chances  for  success  because  it  allows  for  focus  to  be  placed  in  the  right  places.  

Identifying  stakeholders  required  a  set  of  questions  to  be  asked  about  entities  that  were  directly  or  indirectly  involved  with  the  project.[5]  

•   Who  will  directly  use  the  system?  •   Who  will  influence  the  system  (both  internally  and  externally)?  •   Whose  interests  will  be  affected  as  a  result  of  change  in  the  system?  

Following  these  questions,  a  number  of  stakeholders  were  identified:  

Name   Stakeholder  Type   Role   Description  Hasan  Kolcu   Key   Developer   Suggest  and  

actualises  solutions  for  the  problem  

domain.  Undergoes  the  development  process  of  creating  

the  proposed  solutions.  

Suzanne  Embury   Key   Supervisor   Monitors,  guides  and  supports  the  

developer  throughout  the  project  life  cycle.  

Suzanne  Embury   Key   Client   The  person  who  requires  an  

alternate  solution  to  the  problem  

domain.  Helps  shape  the  application  

through  feedback.  Academics   Direct   End  users  of  

produced  application  

Uses  the  finished  application  in  

meetings  to  take  notes/organise  

meetings.  

Academics   Indirect   People  involved  in  academia  

Are  affected  by  indirectly  through  

other  users  following  up  on  action  points.  

Table 2.1: Stakeholders in the Problem Domain

Having  identified  the  stakeholders  in  the  project,  I  will  be  able  to  involve  them  in  phases  of  the  project  where  they  will  be  able  to  contribute  value  to  the  product  produced  through  input  mechanisms  such  as  user  interface  prototyping  through  mockups.    

2.2 Design Approach      There  exist  a  number  of  widespread  design  methodologies  which  define  how  a  problem  is  tackled  throughout  the  course  of  a  design  project.  Each  methodology  is  tailored  to  work  best  under  certain  circumstances.  Big  Up  Front  Design  (BUFR)  is  most  applicable  when  requirements  aren’t  expected  to  change  at  all  throughout  the  project  and  tends  to  follow  a  linear  development  process,  for  example,  Waterfall,  whereas  more  adaptive  methodologies  exist  that  accommodate  for  rapid  change  in  design  requirements  and  provide  transparency  for  all  stakeholders.[6][7]    Each  of  these  practices  have  a  method  of  defining  the  tasks  that  need  to  be  accomplished  for  a  project  to  be  considered  a  success.  It  is  through  these  different  methods  that  requirements  are  gathered  and  documented.    

2.2.1 Requirements Analysis    It  was  important  that  I  chose  a  method  which  was  transparent  and  would  not  lose  detail  when  it  came  to  understanding  the  project  domain.    Written  language  can  be  imprecise  and  often  open  to  interpretation  which  can  cause  developer-­‐customer  miscommunication.  Through  using  user  stories,  emphasis  is  put  on  verbal  communication  which  brings  a  stronger  guarantee  that  the  customer  and  developer  will  have  a  mutual  understanding  of  the  problem  domain.  It  is  for  this  reason  that  I  formed  user  stories  opposed  to  other  practices  such  as  creating  a  straightforward  list  of  all  functional  and  non-­‐functional  requirements.[8]    This  methodology  provides  an  infrastructure  for  project  planning  through  assigning  a  level  of  difficulty/time  needed  to  each  user  story,  which  can  subsequently  be  broken  down  into  smaller  end-­‐to-­‐end  slices,  and  further  estimated,  giving  developers  an  insight  into  how  much  time  and  resources  a  user  story  will  take,  whilst  also  enabling  them  to  focus  on  a  list  of  prioritised  stories  which  deliver  real  value  at  the  end  of  each  project  iteration.    These  user  stories  were  written  in  Michael  Cohn’s  “As  a  <type  of  user>,  I  want  <some  goal>  

so  that  <some  reason>.”  template  so  that  they  could  in  a  short  and  simple  manner,  describe  the  desired  feature  from  the  perspective  of  the  user  who  requires  it.[11]  

Story  No.   Story   Size  (relative)  

Priority  

1   As  an  academic,  I  want  a  highly  productive  way  of  taking  notes  that  is  specialised  for  academic  meetings.  

Large   Very  High  

2   As  an  academic,  I  want  to  be  able  to  manage  sets  of  notes  through  a  simple  mechanism  that  automates  mundane  

tasks.  

Large   Very  High  

3   As  the  chair  of  a  meeting,  I  want  to  be  able  to  assign  action  points  to  

attendees,  and  get  an  overview  of  their  statuses’.  

Medium   High  

4   As  an  participant  in  a  meeting,  I  want  to  be  able  to  share  and  collaborate  notes  

with  other  users.  

Small   Medium  

5   As  a  user  of  the  system,  I  want  to  be  able  to  receive  automatically  

constructed  minutes  of  a  meeting.  

Medium   Low  

 Table  2.2:  User  Stories  for  the  proposed  solution.  

 As  mentioned  above,  the  user  stories  were  purposefully  kept  vague  as  to  ensure  a  correct  and  mutual  understanding  of  the  proposed  solution/problem  domain  was  established.    

2.3 Platform Choice    There  is  a  wide  variety  of  different  tablets  in  the  market,  each  of  which  run  a  specific  platform.  The  main  platforms  used  in  this  market  are  Android,  iOS,  Windows.  Two  main  ways  exist  to  create  applications  on  any  of  these  platforms.  Web  based  applications,  and  native  applications.  Native  applications  bring  the  principal  advantage  that  the  user  experience  is  enhanced  and  optimised  as  the  application  will  operate  quickly  and  seamlessly  with  the  platform  as  it  has  been  designed  specifically  for  it.  Not  going  for  a  web  based  application  does  however  mean  that  if  the  application  needed  cross  platform  operability  we  would  need  to  design  an  application  (relatively)  from  scratch  for  each  platform.  However,  cross  platform  operability  is  outside  the  scope  of  this  project  so  it  was  decided  that  creating  a  native  application  was  the  best  course  of  action  for  this  project.[12]    The  focus  now  shifted  to  which  of  the  three  main  platforms  would  be  chosen.  There  were  a  number  of  factors  that  played  in  on  this  decision:  development  tools,  APIs,  deployability  and  user  friendliness.    Although  Android  devices  hold  the  bigger  market  share  in  the  tablet  sector,  there  are  a  lot  

of  different  Android  devices  which  create  a  lack  if  consistency  between  device  usability.  An  analysis  that  attempts  at  gauging  the  user  experience  of  tablets  compared  different  tablets  across  all  platforms  on  a  number  of  different  criteria,  it  was  found  that  the  Apple  iPad  which  runs  on  the  iOS  platform  had  the  least  cognitive  load,  meaning  users  could  adopt  the  device  whilst  having  little  or  no  knowledge  of  the  works  or  usage  patterns  of  the  device.  This  in  addition  to  the  iPad  being  the  clients  preferred  device  of  usage  gave  the  iOS  platform  a  boost  in  the  race  for  platform  choice.  

   Figure  2.1:  Cognitive  Load  Index  of  different  tablets  in  the  market.[28]  

 Windows  was  eliminated  as  the  deployment  platform  at  this  stage  as  the  resources  to  deploy  onto  a  physical  device  were  not  available  at  the  time.  Since  this  project  is  based  around  interacting  with  the  user  through  an  interface,  an  integrated  development  environment  was  a  must.  Both  Android  and  iOS  provide  development  studios,  Anroid  Studio  and  XCode  respectively.  After  experimenting  with  both  IDEs,  I  found  that  XCode  offered  easier  integration  with  the  front-­‐end  design  and  back-­‐end  than  Android  Studio,  a  feature  that  especially  stood  out  for  me  was  ‘Auto  Layout’  which  allows  for  constraints  to  be  set  on  all  views  in  a  view  hierarchy  and  dynamically  calculates  size  and  positioning  of  objects  in  accordance  with  the  orientation,  state  and  screen  size  of  the  iOS  device.  This  is  done  for  both  internal  changes  within  the  application  and  external  changes  that  can  affect  the  device  view.    

 Figure  2.2:  XCode’s  Autolayout  Feature.  Allowing  relative  positioning  through  use  of  units  to  

position  objects  in  the  view  stack.[15]    

Whilst  Android  did  have  more  open  source  APIs  available,  iOS  also  provided  the  basic  rich  text  editing  APIs  that  were  needed  to  establish  some  of  the  basic  functionalities  of  the  application,  it  was  this  alongside  the  development  environment  and  overall  user  experience  achievable  through  iOS  devices  that  led  to  the  decision  to  produce  an  iOS  application  aimed  primarily  at  tablet  devices  such  as  the  iPad  mini,  whilst  also  encompassing  usability  on  other  iOS  devices  such  as  the  iPhone.  It  should  be  noted  that  iOS  deployment  to  the  app  store  is  a  long,  tedious  and  expensive  process,  however,  this  isn’t  of  great  concern  within  the  project  scope.    

 Figure  2.3:  Tablet  Market  Share  in  the  UK  as  of  August  2015.[13]  

2.4 Application Architecture  Through  adhering  to  the  basic  principles  of  the  Model-­‐View-­‐Controller  (MVC)  architecture  we  are  able  to  separate  the  application  program  into  distinct  sections.[14]  In  doing  so  we  create  maintainable  and  reusable  code  that  follows  a  logical  architecture  in  which  the  data  logic,  presentation  logic  and  business  logic  are  entities  on  their  own  and  interact  and  integrated  only  when  need  be.  Figure  2.4  shows  illustrates  an  abstract  architecture  of  the  system.    

 

Figure  2.4:  The  architecture  of  the  system.    The  model  holds  the  structure  of  the  data  and  provides  methods  for  accessing  the  database,  whether  this  be  to  create,  read,  update  or  delete  data.  The  view  is  composed  of  different  ‘scenes’  consist  of  sub-­‐views  which  can  contain  items  that  the  user  can  directly  or  indirectly  interact  with,  this  includes  gestures  such  as  swiping  in  from  the  side  of  the  screen  to  bring  out  a  menu.  

 

 Figure  2.5:  illustrates  how  a  view  is  broken  into  logical  sections,  with  each  relevant  part  of  the  view  being  contained  in  containers  that  are  restricted  to  a  certain  portion  and  

positioning  on  the  screen.    The  specific  styling  of  items  can  be  altered  through  the  IDE’s  Attributes  Inspector.  

 

 Figure  2.6:  The  Attributes  Inspector.  This  is  particularly  useful  when  the  attributes  of  items  

such  as  text  fields  for  password  entry  are  being  used,  as  it  allows  for  secure  text  entry  attributes  to  be  set,  amongst  other  things.  

The  controller  connects  the  model  to  the  view,  holding  various  business  logic  to  complete  each  task,  this  can  be  anything  from  setting  up  the  next  view  to  load  or  something  as  trivial  as  database  access.  This  control  logic  allows  for  any  requests  made  by  the  user  to  be  processed  and  facilitates  the  flow  of  the  application  for  the  user.    To  allow  for  the  application  to  be  more  maintainable  and  readable,  code  to  access  data  is  stored  logically  within  the  model  (object)  classes  that  represent  the  data.  When  the  database  access  is  required  this  is  done  through  referencing  procedural  calls  with  the  required  parameters.    Through  using  this  architecture  it  is  easy  to  ensure  that  data  changes  within  the  model  are  automatically  reflected  in  the  view  by  placing  procedures  within  the  control  logic.    

2.5 Technology Selection    A  variety  of  different  technologies  have  been  used  in  this  project.  Great  focus  has  been  put  into  learning  and  optimising  program  logic  through  these  technologies,  with  Firebase  being  the  most  interesting  technology  used.    Swift  2.0  iOS  development  is  supported  by  two  programming  languages:  Swift  and  Objective-­‐C.  Projects  written  in  Swift  can  benefit  from  a  feature  called  ‘mix  and  match’  through  which  a  mixed-­‐language  codebase  is  achievable.  This  allows  for  features  from  either  languages  to  be  used  and  incorporated  together  at  a  later  stage  in  the  project.[16]    Swift  2.0  is  a  multi-­‐paradigm  language  which  groups  together  Functional,  Object  Oriented  (OO)  Protocol-­‐Object  Oriented,  Imperative  and  Block  Structured  programming,  producing  a  concise  language  which  is  intended  to  be  more  resilient  than  its  counter-­‐part  to  erroneous  code.  It  is  through  swift  that  we  are  able  to  make  the  application  more  responsive  by  optimising  when  things  get  loaded  onto  the  view.  For  example,  if  the  user  were  to  navigate  to  a  view  where  they  expected  to  see  a  list  of  meetings,  they  would  expect  the  list  to  be  populated  as  soon  as  the  view  loaded,  we  accomplish  this  with  swift  through  placing  set  up  code  in  relevant  view  controller  methods  which  dictate  when  a  block  of  code  is  executed.  In  the  case  of  the  list  of  meetings,  we  access  the  database  and  populate  the  local  data  store  before  the  view  has  appeared  in  the  viewWillAppear()  method.  

 Figure  2.7:  The  View  cycle.  Different  view  controller  methods  which  require  correct  and  

appropriate  use  in  order  to  efficiently  build  up  and  tear  down  a  view  that  the  user  navigates  to.[17]  

 The  alternative  to  using  Swift  2.0  as  the  primary  programming  language  in  this  iOS  project  was  to  use  Objective-­‐C.  However  after  assessing  both  languages,  taking  into  account  flexibility,  syntax  and  learning  curves,  I  decided  that  Objective-­‐C  required  time  that  was  not  available  in  the  scope  of  this  project  in  order  to  grasp  the  language  to  a  level  which  would  produce  a  working  end  product.[18]    Another  advantage  that  brought  me  to  choosing  Swift  over  Objective-­‐C  were  the  Swift  Playgrounds  in  XCode.  Through  playgrounds  I  was  able  to  code  interactively  which  allowed  me  to  write  lines  of  code  whilst  getting  feedback  along  the  way.  This  definitely  helped  improve  the  speed  at  which  code  was  written  as  it  provided  visual  aid  as  code  was  written,  allowing  me  to  focus  on  solving  bigger  problems  rather  than  focusing  on  mundane  details.    The  biggest  advantage  was  the  learning  curve.  Because  Swift  uses  mostly  Object-­‐Oriented  concepts  and  has  a  very  simple,  straightforward  syntax,  I  was  able  to  quickly  pick  up  the  language  with  very  few  limitations  that  were  overcome  by  going  through  extensive  language  documentation.    Firebase  The  iOS  architecture  provides  a  set  of  well-­‐defined  system  interfaces,  with  each  layer  building  upon  lower  layers  to  provide  more  sophisticated  services.  It  is  in  the  Core  Services  layer  that  we  find  the  Core  Data  framework.  This  framework  allows  for  managing  model  objects  in  an  iOS  application.  It  requires  for  objects’  to  subclass  NSManagedObjectModel  which  provides  mapping  from  inbuilt  XCode  data  modelling  facilities  to  written  object  classes.  An  alternative  to  the  Core  Data  framework  was  to  use  the  NSCoding  protocol  as  a  

means  of  providing  a  persistent  storage  mechanism.  This  is  a  lightweight  storage  mechanism  and  works  well  within  small  applications,  however  due  to  the  highly  interactive  nature  that  the  solution  to  this  problem  domain  requires,  this  method  was  only  briefly  incorporated  in  the  initial  stages  of  development.  [19]    

 Figure  2.8:  The  iOS  architecture  structure.[16]  

 Before  using  the  Core  Data  framework,  I  decided  to  explore  different  data  storage  solutions  that  were  available  for  iOS.  It  is  through  this  that  I  came  across  the  Firebase  database  API.  Firebase  provides  backend  services  for  building  mobile  applications.  It  has  cross-­‐platform  support  and  stores  data  in  JSON  format,  synchronizing  data  in  real-­‐time  to  every  connected  client.    The  API  provides  offline  support  by  automatically  triggering  local  events  when  a  write  is  made,  once  a  connection  is  re-­‐established  the  client-­‐server  state  is  synchronised.  In  addition,  an  authentication  system  exists  within  the  API  that  is  relatively  easy  to  incorporate  into  the  project  as  well  as  providing  great  application  scalability  for  possible  future  endeavors.  After  ensuring  the  Firebase  API  would  be  fully  compatible  with  my  project  domain,  it  was  decided  that  Firebase  would  be  the  data  storage  method  for  this  project.  [20]    JSON  JavaScript  Object  Notation  (JSON)  was  used  in  conjunction  with  the  Firebase.  JSON  is  known  to  be  a  “self-­‐describing”  data  structure  and  proves  easy  to  understand.  Due  to  its  tree  structure,  we  are  able  to  denormalise  data  by  splitting  it  into  separate  paths,  enabling  us  to  download  data  in  segments,  as  it  is  needed.      

2.6 Flattening the Data Structure  The  way  in  which  data  is  stored  is  fundamental  to  the  workings  of  the  application,  and  a  lot  of  forethought  needs  to  be  put  into  this  process  so  that  the  data  can  be  modeled  appropriately.    

Switching  from  relational  database  design  (SQL)  to  a  non-­‐relational  design,  I  had  to  get  rid  of  any  table  based  designs  which  had  to  be  replaced  by  document  based,  key-­‐value  pairs.  Initially  I  thought  this  would  be  limiting  and  inefficient,  as  was  evident  in  my  first  design  of  the  database  structure  in  insert  figure  below.  After  researching  into  the  design  principles  of  NoSQL  databases  I  found  there  to  be  a  world  of  optimisation  opportunities,  allowing  me  to  adopt  an  infinitely  better  design  in  which  through  minor  redundancies,  greater  optimisations  were  made  able.  [19][20]    

 Figure  2.9:  The  initial  database  structure.  Lots  of  data  nesting,  causing  NoSQL  inefficiencies.    Unlike  SQL  databases,  NoSQL  provides  horizontal  scalability.  This  is  achieved  through  partitioning  data  logically  by  anticipating  how  the  data  will  be  read  back  later  and  how  to  make  this  process  as  easy  as  possible.  Horizontal  scalability  facilitates  data  flattening,  in  which  data  is  denormalised,  avoiding  data  nesting  wherever  possible.  Data  nesting  can,  and  is  avoided  in  my  design  through  using  indices  when  defining  complex  relationships  such  as  attributing  a  number  of  meetings  to  a  meeting  set.  Instead  of  nesting  the  meetings  within  a  

meeting  set,  the  two  entities  are  defined  separately  and  the  relationship  is  stored  with  minor  redundancies  in  each  entity  (there  is  no  duplication  of  data,  only  references).[20]  

 Figure  2.10:  Finalised  database  structure.  Data  is  flattened,  making  use  of  referencing  

instead  of  nesting  data.      

2.7 Application Design

2.7.1 User Interface Design  Initial  drawings  of  the  applications  UI  were  made,  which  were  then  realised  by  computer  mockups  in  order  to  grasp  whether  or  not  the  envisaged  application  met  the  client’s  needs.    These  designs  were  later  changed  through  paper  prototypes  in  order  to  produce  a  better  flowing  application  and  enhance  the  user  experience.[9]    

 Figure  2.11:  Initial  sketch  of  the  application  view.  

 

 Figure  2.12:  Initial  sketches  of  the  anticipated  toolbar.  

 

 Figure  2.13:  Mockup  of  the  application  in  early  stages  of  development.  

 

2.7.2 Technical Design  The  inner  workings  of  the  application  were  anticipated  through  realising  each  user  story  and  its  design  counterparts.  These  design  counterparts  were  brought  straight  into  the  design  in  the  form  of  an  storyboard  ,  this  allowed  for  defining  the  relationships  between  different  scenes  of  the  application,  view  controllers,  and  how  controls  would  be  used  to  navigate  through  the  application.  This  was  done  all  at  the  very  start  of  the  design  process,  and  allowed  for  the  application  to  be  simulated  with  no  back-­‐end  functionality.  This  affirmed  that  the  design  flow  of  the  application  was  aligned  with  providing  a  good  user  experience.  Although  in  some  places  the  flow  was  altered  after  receiving  feedback.[10]      

     

Figure  2.14:  Storyboard  of  the  Notes  module  in  the  application.    

 Figure  2.15:  The  different  scenes  within  the  application.  These  scenes  are  visualised  in  figure  2.14,  with  the  segues  connecting  and  defining  the  flow  from  scene  to  scene.  

   

 

 

Chapter  3  

Implementation    The  implementation  of  the  iOS  application  is  discussed  within  this  chapter,  with  primary  focus  on  the  Swift  and  Firebase  areas  of  the  application.  There  were  some  issues  that  the  author  was  faced  with  during  development.  The  approach  and  resolutions  of  these  issues  are  highlighted  in  this  chapter.  There  is  a  section  on  how  the  database  structure  was  finalized  and  an  overview  of  how  the  data  is  organised  for  the  application.  A  variation  of  the  Agile  approach  was  used  in  development,  these  practices  are  briefly  explained  and  an  insight  is  given  on  how  their  usefulness  within  the  project.    

3.1 Implementing the Application  It  was  decided  that  the  application  should  be  split  into  modules,  each  module  grouping  together  relevant  functionalities.  Four  core  modules  emerged:  Notes,  Progress  Tracker,  Scheduler  and  Contacts.    

 Figure  3.1:  Tab  view  controller.  Provides  a  constant  reference  point  to  navigate  through  the  application.  All  subsequent  views  lie  underneath  the  Tab  Controller  in  the  navigation  stack.    Each  one  of  these  modules  contain  any  functionality  that  is  primarily  related  to  itself.  For  example,  the  notes  module  allows  a  user  to:  

1.   Enter  notes  into  the  system.  2.   Manage  and  edit  notes  in  the  system.  3.   Delete  notes  from  the  system.  

Each  module  will  be  described  in  further  detail  in  section  INSERT  CORRECT  SECTION  HERE.    

3.1.1 Swift Code structure    With  respect  to  the  MVC  architecture,  the  views  for  the  application  are  modeled  as  storyboards.  Storyboards  provide  a  way  to  model  the  size,  layout  and  positioning  of  containers  in  the  view.  Links  are  made  with  items  in  the  storyboard  to  the  code  files  that  are  view  controllers.  Appearance  attributes  of  elements  in  the  storyboard  is  altered  through  code  in  some  places  and  through  the  IDE  in  others.      

   

Figure  3.2:  Storyboard  and  View  Controller  file  structure.  Source  files  are  split  into  logical  folders,  with  each  accounting  for  a  specific  module.  

 All  visual  alterations  at  a  global  level  are  made  through  the  AppDelegate  class,  it  is  through  this  class  that  the  application  interacts  properly  with  the  system  it  has  been  deployed  on.  This  includes  responding  to  state  transitions  such  as  the  application  being  moved  from  foreground  to  background  execution.  

 

   

Figure  3.3:  A  snippet  from  the  AppDelegate  class.  Here  the  colour  scheme  for  the  application  is  being  set  on  a  global  level.  

 All  data  entities  are  modelled  into  various  objects,  each  having  accessor  methods  and  update  methods  that  are  linked  to  the  Firebase  database.    

 

   

Figure  3.4:  Structure  of  a  User  in  Swift  code.    Data  is  queried  through  listener  methods  that  keep  local  and  remote  data  copies  consistent  in  real-­‐time.  These  asynchronous  listeners  require  building-­‐up  and  tearing-­‐down  in  their  appropriate  places  and  are  triggered  once  for  the  initial  state  of  data  and  again  anytime  that  there  is  a  change  in  data.    Transitions  from  one  view  to  another  are  accomplished  through  segues.  It  is  the  navigation  controller’s  primary  responsibility  to  respond  to  user  actions  (which  are  realised  through  segues)  by  pushing  new  content  view  controllers  onto  the  stack  or  popping  content  view  controllers  off  of  the  stack.  Depending  on  the  type  of  segue  the  stack  will  be  altered  in  different  ways.    

   

Figure  3.5:  The  iOS  navigation  stack.  [21]    

   

Figure  3.6:  The  different  types  of  Segues.  Each  type  results  in  a  unique  transition  that  affects  the  navigation  stack  differently.  It  is  important  to  use  the  correct  segues  as  we  want  to  achieve  maximum  efficiency.  This  means  there  should  be  no  unnecessary  segues  on  the  

navigation  stack.[16]    

3.1.2 Firebase integration

 

3.1.2.1 Integration  Integration  with  Firebase  required  for  the  API  to  be  included  in  the  project  build.  The  decision  to  use  Firebase  brought  with  it  many  advantages,  one  being  that  the  same  database  could  be  used  in  the  future  if  an  Android  version  of  the  product  were  to  be  developed.  This  meant  that  the  Firebase  module  had  to  be  imported  into  each  class  which  required  a  database  connection.    

3.1.2.2 Issues Faced    Queries  to  the  database  had  to  be  carefully  placed  and  built.  This  posed  difficulties  as  the  relational  dependencies  through  the  likes  of  foreign  keys  are  non  existent  in  NoSQL,  this  meant  having  to  structure  the  data  in  such  a  way  that  the  key-­‐value  pairs  NoSQL  provides  could  be  used  for  quick  and  easy  access/storage.  Flattening  the  data  was  an  essential  part  of  this  operation  as  it  made  the  direct  path  to  a  piece  of  data  shorter  by  removing  unnecessary  links  that  would  otherwise  be  prevalent  if  a  relational  architecture  were  to  be  imposed  on  the  NoSQL  database.    

3.1.2.3 Issues to Overcome  Although  user  authentication  had  been  implemented,  it’s  crucial  counterpart  data  authorisation  was  lacking.  This  meant  that  there  was  no  control  over  who  had  access  to  user  data.        To  tackle  this,  some  security  rules  were  written  to  specify  the  type  of  access,  if  any,  a  user  had  to  the  database.  A  rule  that  was  applied  to  a  node  in  the  database  cascaded  to  all  of  its  children.[22]    

 

 Figure  3.7:  Firebase  security  rules.  This  specific  rule  grants  write  access  on  the  path  /users/<auth.uid>/  to  the  user  whose  unique  ID  matches  the  dynamic  path,  $user_id.  

 

3.1.2.4 Remaining Issues  It  should  be  noted  that  data  validation  rules  could  not  be  implemented  explicitly  within  the  timescale  of  this  project,  however  the  integration  of  these  would  not  require  alteration  in  any  source  code,  rather,  it  would  require  the  author  to  write  a  set  of  validation  rules  for  the  Firebase  database.    

3.2 Approach  The  development  process  undertaken  was  based  loosely  around  agile  methods  and  techniques.  An  iterative  and  incremental  approach  was  taken.      The  main  agile  methods  and  techniques  incorporated  into  the  development  process  are  prioritisation  and  test-­‐driven  development  (TDD).    

3.2.1 Prioritising functionality  It  is  difficult  to  access  how  much  effort  and  time  a  specific  user  story  will  require  on  its  own.  An  agile  methodology  to  overcome  this  problem  is  to  use  relative  sizing  to  determine  story  sizes.  This  involves  picking  out  the  difference  between  a  small,  medium,  large  t-­‐shirt  for  example.  Each  story  is  judged  and  accessed  relatively  to  others.  It  is  through  applying  this  technique  that  I  was  able  to  have  a  guideline  to  which  functionalities  I  should  focus  on  implementing  first,  and  grasp  an  idea  of  how  much  of  what  I  set  to  accomplish  was  attainable.    

3.2.2 Test Driven Development  The  primary  aim  behind  TDD  in  this  project  was  to  create  clean,  thorough  code  that  delivers  real  value  and  continuously  improves  on  these  factors.  Adapting  this  approach  meant  that  I  had  a  very  short  development  cycle  in  which  at  the  end  of  every  cycle,  the  value  delivered  constantly  increased  through  adding  new  functionality  or  refactoring  existing  functions.[29]    An  improvement  to  this  technique  could  have  been  applied  through  which  tests  would  have  

been  fully  automated  and  co-­‐written.  However,  due  to  the  nature  of  this  being  an  individual  project,  the  driver/navigator  aspect  of  pair-­‐programming  could  not  be  made  use  of.    

3.3 Database Structure  

The  majority  of  the  database  structure  was  implemented  in  the  intial  stages  of  the  product  and  resulted  in  the  final  structure  mentioned  in  section  2.6.  The  structure  facilitated  storage  of  meta-­‐data  regarding  system  users,  meeting  data  such  as  notes,  action  points  and  attendees,  invitations  to  join  shared  meeting  notes  and  more.[20][23]    The  horizontal  distribution  of  data  meant  that  functionality  could  be  easily  added  without  change  to  the  structure  of  the  data  or  even  if  change  needed  to  be  done  to  the  structure  this  could  be  done  with  minimal  to  no  affects  to  other  parts  of  the  system.  The  scalability  of  the  application  can  also  be  attributed  to  the  structure,  as  it  results  in  a  reduced  computational  workload  for  server  side  machines  that  don’t  need  to  look  up/follow  complex  relational  queries  or  paths  to  retrieve/save  data.    The  structure  of  the  database  created  for  this  project  is  arguably  the  most  core  feature  behind  the  workings  of  the  application.        

Chapter  4  

Results    This  chapter  will  discuss  the  results  of  the  iOS  application  produced  for  this  project.  The  individual  modules  will  be  discussed  in  turn,  describing  the  functional  value  for  the  end-­‐user.  Each  module  will  hold  a  series  of  screen  shots,  explaining  how  the  module  works  and  its  interactions  with  the  rest  of  the  system.  

4.1 The Log-in Module  The  log-­‐in  view  is  very  simple  to  understand.  This  is  shown  in  Figure  4.1.  

 Figure  4.1:  Log-­‐in  screen  for  the  iOS  application.  

 Validation  is  done  server-­‐side,  only  permitting  registered  users  to  enter  the  application.  Password  entry  is  done  through  a  secure-­‐entry  text  field  module  and  authentication  is  done  through  Firebase.  Users  can  also  register  new  accounts  which  will  also  be  validated  to  ensure  consistency.  Once  the  user  enters  correct  credentials  they  are  taken  to  the  central  view  of  the  application.    

 

4.2 Note Taking Module  It  is  in  this  view  of  the  application  that  notes  are  taken  and  edited.  The  application  provides  a  quick  an  easy  means  of  rich  text  editing  which  is  achieved  through  HTML  formatting.  There  is  automatic  extraction  of  data  when  notes  are  typed  up.  This  includes  automatic  separation  of  the  title,  notes  and  the  date  and  time  of  the  meeting.      The  toolbar  is  accessible  at  all  times  during  note  entry  as  to  provide  rapid  access  to  functionality  such  as  entry  of  action  points,  inviting  collaborators  or  even  text  formatting  options.  This  provides  a  better  overall  user  experience  by  creating  a  constant  reference  point  and  is  very  instinctive  to  pick  up.  Existing  action  points,  completed  or  pending  can  be  seen  in  the  slide  menu  on  the  left  hand  side  of  the  application.  The  status  of  action  points  can  be  marked  through  this  side  menu  which  is  instantly  reflected  in  the  database.  If  an  action  point  is  incomplete  and  the  deadline  is  nearing,  a  local  notification  appears  to  the  assignee,  reminding  them  and  taking  them  to  view  the  action  point.    

   Figure  4.2:  The  Note  Taking  View.    The  toolbar  (bottom  of  screenshot)  is  always  present.  

Having  this  specifically  tackles  issue  of  aligning  the  mental  tasks  of  adding  attendees  /  action  points  etc.  with  how  these  tasks  are  logically  carried  out  in  real  life  and  guides  the  user  through  this  process.  The  process  becomes  instinctive  and  is  much  better  than  the  initial  

entry  method  through  which  separate  text  fields  were  used  which  assumed  that  users  know  exactly  what  they  need  to  do  and  relies  on  trial  and  error  for  the  user  to  learn  the  process,  

rather  than  them  being  able  to  pick  it  up  naturally.    

 

 Figure  4.3:  Action  Point  reminder  notification.  

 It  should  be  noted  that  notifications  were  added  at  a  later  stage  in  development,  and  due  to  lack  of  foresight  the  program  structure  didn’t  directly  accommodate  the  integration  of  

passing  data  to  notifications  from  different  views.  For  this  reason,  the  iOS  notification  centre  was  used,  which  in  essence  stored  some  data  in  the  form  of  global  variables.    

4.3 Contacts Module  In  light  of  providing  user  collaboration,  it  was  decided  that  a  system  was  required  to  establish  trusted  contacts.  Users  can  add  other  users  of  the  system  to  their  trusted  collaborators  list,  this  will  cause  a  request  to  be  sent  to  the  other  user,  establishing  mutual  trust.  

   

Figure  4.4:  Firebase  application  database.  Here  we  see  the  database  in  real  time  when  a  contact  request  is  accepted.  The  request  being  accepted  alters  existing  data  in  the  relevant  

places,  whilst  inserting  new  data  where  necessary.  

 

4.4 Incomplete Functionality  It  was  decided  that  in  addition  to  the  progress  tracker  provided  in  the  note  editorial  view,  a  separate  module  would  be  created  to  provide  an  overview  of  progress,  the  core  underlying  support  was  built  for  this  module,  however  integration  with  the  user  interface  could  not  be  completed  in  the  timescale  of  this  project.    In  addition  to  the  progress  tracker,  a  scheduler  module  was  designed  and  some  of  the  back  end  functionality  was  complete,  such  as  setting  reminders,  however  this  module  was  also  not  completed  within  the  timescale  of  the  project.    

Chapter  5  

Testing  and  Evaluation    This  chapter  details  the  testing  processes  applied  to  the  project.  The  final  section  evaluates  the  project’s  achievements  and  quantifies  the  value  delivered  with  an  indication  of  the  correctness  and  quality  of  the  application  that  was  produced.    

5.1 Testing

5.1.1 Test Driven Development  As  mentioned  is  section  X  a  variation  on  the  widely  applied  test  driven  development  approach  was  used  in  the  planning  and  development  of  this  project.  Through  adapting  TDD  to  the  development  of  the  project,  the  author  was  able  to  make  quick,  substantive  progress  in  development  by  initially  adding  small  increments  of  functionality,  eventually  building  up  a  more  complex  system.  This  involved  writing  an  initial  failing  test  for  the  component,  writing  the  minimum  amount  of  code  required  for  the  test  to  pass,  refactoring  the  code,  and  repeating  the  process  until  the  code  complied  with  acceptance  tests.    

5.1.2 Unit Testing  

Unit  testing  was  used  to  test  functionality  done  on  small  components  of  the  system.  This  was  accomplished  through  manual  testing  via  the  User  Interface  of  the  application,  ensuring  that  data  changes  in  the  database  were  synchronised  with  the  changes  in  the  local  application.  In  hindsight,  it  would  have  been  best  to  have  automated  these  tests  as  to  save  time  and  ensure  that  no  test  cases  went  unchecked.      While  unit  testing  ensures  that  each  individual  unit  is  functioning  correctly,  it  does  not  take  into  account  the  interactions  between  units,  for  this  reason  integration  testing  was  applied  to  all  modules  that  interacted  with  other  parts  of  the  system.  In  hindsight,  regression  testing  was  grossly  overlooked.  To  cover  this  in  future  workings,  an  automated  testing  suite  such  as  Calabash  that  provides  execution  of  automated  acceptance  tests  on  the  iOS  platform  should  be  used.  [24][25]    

5.1.3 Testing Overview  It  is  the  author’s  belief  that  the  functionality  provided  was  tested  to  a  good  standard  through  the  methods  mentioned  above,  and  this  is  echoed  through  the  confidence  with  which  user’s  can  use  the  system’s  completed  functionalities.  A  more  thorough  testing  procedure  could  have  been  undertaken,  and  in  any  future  work,  the  author  would  strive  to  create  automated  tests  for  UI  interactions.  Through  doing  so,  valuable  time  and  resources  could  be  spent  more  productively  when  the  whole  development  life  cycle  is  taken  into  consideration.      

5.2 User Evaluation  The  motivation  behind  this  project  was  to  provide  a  solution  to  a  real-­‐life  problem,  it  was  therefore  important  to  gather  feedback  from  stakeholders  of  the  system,  as  to  provide  feedback  about  the  system  they  were  going  to  use.  Unfortunately,  this  opportunity  was  not  made  available  for  all  key  stakeholders  of  the  system,  however,  a  questionnaire  was  created  in  light  of  receiving  feedback.    The  feedback  received  was  constructive  and  helped  immensely  in  shaping  the  flow  and  features  of  the  application,  giving  an  insight  into  the  perceived  user  experience.    

 Figure  5.1:  Feedback  from  the  earlier  stages  of  the  development  cycle.  

 

 Figure  5.2:  User  feedback  on  action  point  entry  system.  Following  this  feedback,  a  notification  feature  was  added  to  remind  users  of  upcoming  action  point  deadlines.  

 

 Figure  5.3:  Final  user  comments  on  the  tablet  application.  

 

5.3 Developer Evaluation  The  author  found  that  working  on  an  individual  project  required  for  external  perspective  to  be  put  into  the  application,  as  it  was  found  to  be  difficult  making  design  decisions  which  would  inevitably  have  a  huge  effect  on  the  user  experience.  For  this  reason,  it  should  be  noted  that  the  author  constantly  undertook  face  to  face  evaluations  on  a  regular  basis  throughout  the  user  interface  development  of  the  application.    

Chapter  6    

Conclusion  and  Future  Work    The  goals  and  objectives  behind  the  project  are  analysed  in  this  chapter,  explaining  how  they  transformed  and  achieved  throughout  the  span  of  this  project.  The  struggles  behind  learning  mobile  development  from  scratch  are  highlighted  as  well  as  other  areas  of  personal  development.  A  brief  summary  of  the  report  is  also  provided.  

6.1 Reviewing Original Objectives  The  three  core  objectives  in  accomplishing  this  project  were:    

1.   To  learn  iOS  development  independently  through  the  use  of  available  resources  to  an  extent  where  a  mobile  application  ready  for  deployment  can  be  produced.  

2.   To  produce  a  secure  iOS  application  to  be  used  by  academia,  allowing  them  to  efficiently  take  and  manage  notes  in  meetings,  and  providing  a  way  of  sharing  data  with  colleagues.  

3.   To  evaluate  the  overall  effectiveness  of  the  tablet  application  and  its  usability  by  academics  to  see  if  the  application  contains  the  necessary  features  to  tackle  the  problems  faced  that  were  outlined  in  SECTION  X    

The  first  objective  was  definitely  achieved,  the  proof  of  this  is  evident  in  the  development  and  results  section  of  this  report.  The  process  of  self-­‐teaching  a  completely  new  development  concept  was  difficult  at  first,  but  after  researching  and  following  various  books  on  Swift  programming  and  iOS  development,  I  was  able  to  gain  an  understanding  of  the  underlying  concepts  behind  mobile  development  and  able  to  transfer  these  newly  gained  skills  into  creating  a  functional  artefact.    The  second  objective  was  partially  fulfilled.  Although  a  working  product  was  produced,  the  application  had  some  incomplete  modules  that  did  not  pass  acceptance  testing.  Application  security  was  provided  by  a  solid  database  structure  with  security  rules,  however  some  data  was  not  validated  and  therefore  left  the  system  susceptible  to  the  usage  of  incorrect  or  inconsistent  data  in  rare  circumstances.      The  third  objective  was  partially  achieved  as  highlighted  by  the  feedback  that  was  received  from  users,  however,  one  of  the  key  stakeholders  was  unable  to  try  out  the  finished  product.  This  was  very  unfortunate  as  the  use  of  the  application  in  the  environment  it  had  been  designed  for  would  have  proved  very  useful  in  the  development  of  the  application.    The  most  time  consuming  of  these  by  far,  was  learning  iOS  development.  It  required  understanding  and  applying  a  lot  of  new  programming  practices  and  concepts  such  as  the  use  of  storyboards  and  application  flow  management  in  order  to  put  together  a  functional  application.    

6.2 Personal Development  The  importance  of  programming  practices  such  as  TDD,  ATDD  and  useful  user  evaluation  techniques  have  been  reaffirmed  throughout  the  span  of  this  project.  Also,  new  technologies  have  been  learnt  in  the  creation  of  this  project.  Swift  2.0,  the  XCode  IDE  and  Firebase  have  opened  up  a  lot  of  development  opportunities  for  myself.  The  steep  learning  curves  I  was  faced  with  in  iOS  development  have  returned  great  benefits  as  I  now  have  a  thorough  and  deeper  understanding  of  the  planning  and  development  commitments  that  are  required  to  build  mobile  applications.  The  aid  of  creating  prototypes  proved  to  be  very  useful  in  terms  of  both  time  and  development  efforts,  they  provided  a  way  for  both  the  developer  and  end-­‐users  of  the  system  to  envisage  the  product  that  was  about  to  be  created  whilst  providing  an  opportunity  to  address  any  concerns  regarding  the  visual  design  of  the  application.    

6.3 Future work  Throughout  this  report,  the  author  has  constantly  reflected  on  improvements  that  could  be  made  to  the  planning,  design,  implementation  and  testing  phases  of  this  project.  It  can  be  said  with  high  certainty  that  a  lot  of  the  practices  applied  were  successful,  however,  came  into  use  in  the  later  stages  of  the  project.    As  milestones  and  requirements  changed,  these  practices  were  partially  forgotten  and  put  to  the  side.  This  was  a  shortcoming  on  the  author’s  side,  as  the  very  practices  that  were  neglected  would  have  worked  exceptionally  well  with  the  given  circumstances.  For  instance,  short  iterations  meant  that  changes  in  requirements  didn’t  have  much  of  an  overall  effect,  and  this  practice  was  kept  up.  However  other  agile  practices  such  as  Wizard  of  Oz  testing  which  were  initially  key  drivers  of  the  design  process  were  put  to  the  side  as  requirements  changed.  This  caused  a  lack  of  foresight  and  resulted  in  time  delays  further  along  in  the  project.    If  the  application  were  to  be  published  in  the  app  store,  its  database  design  would  allow  for  app  scalability  on  a  large  scale.  Given  the  database’s  flattened  architecture,  an  increase  in  user  requests  would  not  lead  to  delayed  responses  within  the  application  due  to  the  nature  of  Firebase’s  data  service.    In  applying  these  practices,  the  rest  of  the  application’s  functionality  is  feasible  to  be  fully  completed  in  4  extra  iterations  (three,  one  week  iterations  and  one,  two  week  iteration).                                            

References  1.  Sutherland  J.  Scrum.  London:  Random  House  Business  Books;  2015.    2.  Crosby  B.  Stakeholder  Analysis:  A  Vital  Tool  for  Strategic  Managers  [Internet].  2016  [cited  23  March  2016].  Available  from:  http://pdf.usaid.gov/pdf_docs/PNABR482.pdf    3.  Managing  change  in  organizations.  Newtown  Square,  Pa.:  Project  Management  Institute;  2013.    4.  Chapter  7.  Encouraging  Involvement  in  Community  Work  |  Section  8.  Identifying  and  Analyzing  Stakeholders  and  Their  Interests  |  Main  Section  |  Community  Tool  Box  [Internet].  Ctb.ku.edu.  2016  [cited  23  March  2016].  Available  from:  http://ctb.ku.edu/en/table-­‐of-­‐contents/participation/encouraging-­‐involvement/identify-­‐stakeholders/main    5.  Project  Management  Life  Cycle  Methodology  [Internet].  Method123.com.  2016  [cited  11  March  2016].  Available  from:  http://www.method123.com/project-­‐lifecycle.php    6.  WATT  A.  3.  The  Project  Life  Cycle  (Phases)  |  Project  Management  [Internet].  Opentextbc.ca.  2016  [cited  10  March  2016].  Available  from:  https://opentextbc.ca/projectmanagement/chapter/chapter-­‐3-­‐the-­‐project-­‐life-­‐cycle-­‐phases-­‐project-­‐management/    7.  Bowes  J.  Agile  vs  Waterfall  -­‐  Comparing  project  management  methods  [Internet].  Manifesto.  2014  [cited  10  March  2016].  Available  from:  https://manifesto.co.uk/agile-­‐vs-­‐waterfall-­‐comparing-­‐project-­‐management-­‐methodologies/    8.  Embury  S.  How  Do  We  Know  What  to  Build?  [Internet].  https://moodle.cs.man.ac.uk/file.php/357/Handouts/UserStories/comp33711_week3_handout_2015.pdf.  2015  [cited  19  April  2016].  Available  from:  https://moodle.cs.man.ac.uk/file.php/357/Handouts/UserStories/comp33711_week3_handout_2015.pdf    9.  User  Interface  (UI)  Prototypes:  An  Agile  Introduction  [Internet].  Agilemodeling.com.  2016  [cited  19  April  2016].  Available  from:  http://agilemodeling.com/artifacts/uiPrototype.htm    10.  About  Storyboards,  Scenes,  and  Connections  [Internet].  Developer.apple.com.  2016  [cited  6  March  2016].  Available  from:  https://developer.apple.com/library/ios/recipes/xcode_help-­‐IB_storyboard/Chapters/AboutStoryboards.html    11.  Cohn  M.  Advantages  of  User  Stories  for  Requirements  [Internet].  https://www.mountaingoatsoftware.com/articles/advantages-­‐of-­‐user-­‐stories-­‐for-­‐requirements.  2004  [cited  7  April  2016].  Available  from:  https://www.mountaingoatsoftware.com/articles/advantages-­‐of-­‐user-­‐stories-­‐for-­‐requirements    

12.  Bolton  D,  Hall  S,  Nwabuoku  A.  A  Scoring  Comparison  of  Android  and  iOS  Development  -­‐  The  New  Stack  [Internet].  The  New  Stack.  2015  [cited  23  March  2016].  Available  from:  http://thenewstack.io/scoring-­‐comparison-­‐android-­‐ios-­‐development/    13.  UK  market  share  of  tablet  manufacturer  2015  |  Survey  [Internet].  Statista.  2016  [cited  3  March  2016].  Available  from:  http://www.statista.com/statistics/476319/uk-­‐market-­‐share-­‐of-­‐tablet-­‐manufacturer/    14.  MVC  Architecture  [Internet].  Developer.chrome.com.  2016  [cited  29  March  2016].  Available  from:  https://developer.chrome.com/apps/app_frameworks    15.  Auto  Layout  Guide:  Understanding  Auto  Layout  [Internet].  Developer.apple.com.  2016  [cited  25  March  2016].  Available  from:  https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/AutolayoutPG/    16.  Swift  -­‐  Apple  Developer  [Internet].  Developer.apple.com.  2016  [cited  20  March  2016].  Available  from:  https://developer.apple.com/swift/    17.  UIViewController  Class  Reference  [Internet].  Developer.apple.com.  2016  [cited  3  March  2016].  Available  from:  https://developer.apple.com/library/ios/documentation/UIKit/Reference/UIViewController_Class/    18.  Using  Swift  with  Cocoa  and  Objective-­‐C  (Swift  2.2):  Swift  and  Objective-­‐C  in  the  Same  Project  [Internet].  Developer.apple.com.  2016  [cited  3  March  2016].  Available  from:  https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html    19.  Features  -­‐  Firebase  [Internet].  Firebase.com.  2016  [cited  3  April  2016].  Available  from:  https://www.firebase.com/features.html    20.  Structuring  Data  -­‐  Firebase  [Internet].  Firebase.com.  2016  [cited  6  April  2016].  Available  from:  https://www.firebase.com/docs/web/guide/structuring-­‐data.html    21.  Navigation  Controllers  [Internet].  Developer.apple.com.  2016  [cited  15  March  2016].  Available  from:  https://developer.apple.com/library/ios/documentation/WindowsViews/Conceptual/ViewControllerCatalog/Chapters/NavigationControllers.html    22.  Understanding  Security  -­‐  Firebase  [Internet].  Firebase.com.  2016  [cited  3  March  2016].  Available  from:  https://www.firebase.com/docs/security/guide/understanding-­‐security.html    23.  Understanding  :  NoSQL  [Internet].  Spring.io.  2016  [cited  5  April  2016].  Available  from:  https://spring.io/understanding/NoSQL    

24.  Calaba.sh  -­‐  Automated  Acceptance  Testing  for  iOS  and  Android  Apps  [Internet].  Calaba.sh.  2016  [cited  1  May  2016].  Available  from:  http://calaba.sh    25.  Instruments  User  Guide:  Automate  UI  Testing  in  iOS  [Internet].  Developer.apple.com.  2016  [cited  3  April  2016].  Available  from:  https://developer.apple.com/library/tvos/documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/UIAutomation.html    26.  Ng  S.  Beginning  iOS  9  Programming  with  Swift.  Appcoda;  2015.    27.  NG  S.  Intermediate  iOS  9  Programming  with  Swift.  3rd  ed.  Appcoda;  2015.    28.  Tablet  User  Experience  Benchmarks.  1st  ed.  Pfeiffer  Consulting;  2013.    29. Beck K. Test-driven development. Boston: Addison-Wesley; 2003. 30. Evernote [Internet]. 2016 [cited 3 May 2016]. Available from: https://evernote.com/ 31. Microsoft OneNote | The digital note-taking app for your devices [Internet]. Onenote.com. 2016 [cited 3 May 2016]. Available from: https://www.onenote.com/  32. Google Docs - create and edit documents online, for free. [Internet]. Google.com. 2016 [cited 3 May 2016]. Available from: https://www.google.com/docs/about/                                                  

 

Appendix  A  

 

Evaluation  Questionnaire  for  the  iOS  Application    The  following  is  an  example  of  the  evaluation  questionnaire  that  was  used  by  users  of  the  developed  application.                                                                  

   

Hyper  Note  –  A  high  productivity  note  taking  application  for  iOS      Evaluation    Note:  this  questionnaire  follows  the  natural  flow  of  the  application.    

1)   Is  the  Login  screen  as  you  expected  it?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

2)    What  do  you  like  about  the  Login  screen?  _______________________________________________________________________________________________________________________________________________________________________________________________________________  

   3)   On  a  scale  of  1  to  5,  how  easy  is  it  to  log  in  (5  being  extremely  easy  and  1  being  

extremely  difficult)?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

4)   Is  there  anything  you  didn’t  like  about  the  Login  page?  _______________________________________________________________________________________________________________________________________________________________________________________________________________  

 5)   How  easy  is  it  to  navigate  through  existing  notes?  

_______________________________________________________________________________________________________________________________________________________________________________________________________________    

6)   Would  you  prefer  a  different  structure  to  viewing  your  existing  notes?  If  you  answered  yes,  how  would  you  like  to  view  them?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

7)   How  easy  is  it  to  create  a  new  set  of  notes?  _______________________________________________________________________________________________________________________________________________________________________________________________________________  

   

8)   Are  you  able  to  fully  express  what  happens  in  your  meetings  through  the  application?  If  you  answered  no,  what  can’t  you  do?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

9)   Are  there  any  redundant  features  whilst  you  are  taking  notes?  If  so,  what  are  they?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

10)  On  a  scale  of  1  to  5,  how  easy  is  it  to  take  notes  (5  being  extremely  easy  and  1  being  extremely  difficult)?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

11)  Do  you  feel  there  are  any  improvements  to  the  layout  that  could  be  made  to  make  the  note  taking  process  easier?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

12)  How  did  you  find  adding  action  points  through  the  application  and  subsequently,  were  you  able  to  manage  them  with  ease?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

13)  Did  you  feel  there  were  any  missing  elements  to  action  point  entry?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

14)  On  a  scale  of  1  to  5,  how  did  you  find  inviting  collaborators  and  managing  your  contacts  (5  being  extremely  easy  and  1  being  extremely  difficult)?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

15)  Did  you  feel  the  contacts  section  of  the  application  missed  any  functionality?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

 16)  Were  there  any  features  in  the  contacts  section  that  you  felt  were  irrelevant?  If  so,  

what  were  they?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

17)  In  your  opinion,  is  there  any  missing  functionality  from  the  application?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

18)  Do  you  think  this  system  will  be  more  beneficial  than  the  system  that  preceded  it?  Please  explain  your  reasoning.  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

19)  What  is  your  overall  level  of  satisfaction  with  the  system  as  a  whole?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

20)  Any  additional  comments?  _______________________________________________________________________________________________________________________________________________________________________________________________________________    

 Thank  you  for  taking  your  time  to  fill  this  questionnaire.  Your  time  is  appreciated.