//****************************************************************************//
//******************* Packages - November 17th, 2017 ************************//
//**************************************************************************//

- So, let's finish talking about some of the techniques you'll use if you choose to do M11

- We JUST started talking about "Cognitive Walkthrough," which is walking through the app like a novice user would
    - FIRST, you have to establish who you want your novice users to be, i.e. "Our target audience is 18-24 year-olds on the Malaysian island of Zamputra, where they've never seen a computer before"
    - Now, for every action, you should list the GOAL(s) of what they want to do, and the STEPS we WANT them to take to try and do it
        - e.g. for a login screen, we'd say that our GOAL is to "login to the app", and the STEPS the user would take is 1) Type username in uName box 2) Type password in pWord box 3) Hit the login button
    - Then, we use a "believability story" to try and evaluate if our steps are something the user would realistically guess 
        - This means asking 4 key questions:
             1) Will the user be trying to produce whatever effect the action has?
                - i.e., do they know what they SHOULD be doing? Is there a reason for them to guess what you want them to do?
            2) Will the user be able to notice that the correct action is available?
                - Is there a login button on the screen? How do they know it's for login? Does our app follow established conventions/expectations?
            3) Once the user finds the correct action on the interface, will they know that it's the right one for the effect they're trying to produce?
                - How do they KNOW what they're doing is related to the goal?
            4) After the action is taken, will the user understand the feedback given?
        - This is ALL about figuring out if the user can figure out what they're supposed to do, and how to do it; "Cognitive Walkthroughs" are NOT about aesthetic design details, but if our design "works"

- Finally, the last technique is THINK-ALOUD, and its whole purpose is to put the app in front of real users and see what they think!
    - This is NOT as easy as you think, but it is one of the best ways to gather feedback about your interface
        - Generally, 5 people is enough for us to find most major problems; after 15 people, diminishing returns means we're getting barely any new information
    - It's called "think-aloud" because you ask the user to tell you what they're thought process is when they're using the app ("okay, I'm opening the login screen now to start using the app, I'm typing my password...")
        - Whatever you do, do NOT intervene if they're struggling to do something! They have to figure out what to do on their own; if they can't figure out how to do something, then it means you've found something to improve! Intervening will just make the test data skewed and biased
    - "There's a BIG spreadsheet on T-Square of how to run a succesful think-aloud test, from a group of professors at University of Washington"

-  So, that's as far as we'll go with UX in this class, but there's a TON more we don't get into, of course

- Now, let's get back into software design

============================
// Packaging Principles
============================

- Now, in the old days, a single program could not have ANY two classes with the same name
    - e.g. If we already had a "Point" class for our X/Y coordinates, we could NOT create a "Point" class to handle our game's score; we'd have to call it something else
- Nowadays, with PACKAGES, we can do this! We can have a "Score" package with a Score.Point class inside, and a "Gameplay" package with a Gameplay.Point class inside!

- These are not *quite* the packages we're talking about right now (although they're related, and in Android studio, the same thing)! INSTEAD, we're talking about when you're ready to ship your application and need to export it into a number of different DEPLOYMENT packages
- Now, when we download most professional applications, it's not just a single 5gb .exe file; it's usually broken up into a bunch of smaller files

- Two main kinds of packaging philosophies: ARCHITECTURAL PACKAGING, and FEATURE PACKAGING
    - Architectural packaging is like knowing that all the low-level employees are on the 1st floor, all the managers are on the 2nd floor, and all the executives are on the 3rd floor
    - Feature packaging is like knowing all the accountants are somewhere in the back-left corner of the 1st floor

- Robert Martin's ideas on deployment principles:
    - No matter HOW we chose to organize something, we're committing to stick to that organization throughout the rest of the time we're working on the application - once we ship it out to the world, we can't change it
    - The 1st principle: the COMMON REUSE principle!
        - If you're re-using code across apps, then all of that code should be in the same package
    - A 2nd principle is COMMON CLOSURE/MAINTENANCE
        - We put all of the code that affects each other together! E.g. if our XML-parsing code changes, we put all of the code that'd be affected by us changing that in the same package
            - "This way, instead of having to re-download the whole app when we release an update, they only have to download the package that changed!"
        - A final thing about code formatting...kind of missed this

- Why do we care about packaging? Well, there's a few reasons, but in the CS world we have to worry about something called the "Morning After Syndrome" ("completely unrelated to drinking, of course")
    - This basically means that someone changes a piece of code without anyone's knowledge, and the next morning, it's broken something else!
    - To counter this, most companies tried to have DAILY BUILDS for the whole software...but that got too complex, since they'd have to spend a chunk of time each day integrating everyone's code together
        - So it became weekly builds, but then integration still would get real messy...which turned into monthly builds...
        - So, we FIXED this problem with something called the ACYCLIC DEPENDENCY PRINCIPLE
            - Basically, we split the software into a number of different packages, and each package team says "Alright, we'll assume that <package we're depending on> will stay at Version 1.0; we won't depend on any functionality after that"
                - This way, if the package they're depending on breaks, they can just roll it back to version 1.0 and still be able to test the rest of the software!
                - Then, if enough cool features get added to the package, the team can decide when to update THEIR package to use version 2.0 of the dependency
            - Moreover, we should NOT have packages depending on one another