1. Videos not working. The video files were not getting to the database insert function. The cause? On the client, I was writing to post.videoPath the URL after the upload finished, but I was reading from post.videoURL. Switching both to use post.videoURL fixed that problem.
2. Video preview. I added a <video> tag to show the video during addition of a post. With <img>, a null src meant the element was invisible. Not so for video. I saw a black window when the video had not yet been recorded. As a workaround, I created an empty <div id="videoPreview"> instead. When the video gets recorded or picked, $("#videoPreview").html('<video src="path/to/video.mov" controls>') did the trick.
3. When inserting text with quotation marks and apostrophes, they were getting escaped by somebody that wasn’t us. Effectively, this meant a lot of backslashes showed up in post titles and bodies. Either the prepared statements business or the magic quoting of PHP was to blame. To unescape, we have to call stripslashes($string).
4. Wait until video uploaded. In order to let the user know that a long upload was taking place, I wanted to progress bar/animation. jQuery came to the rescue with $.mobile.loading('show') and $.mobile.loading('hide').
5. Cookies to auto-authenticate. I ended up using jquery.cookie.js to simplify cookie management. On a successfully login, I store the userid with $.cookie('userid', userid, { expires: 50, path: '/' }). Later, I can retrieve it with $.cookie('userid') and delete it with $.removeCookie('userid') on logout.

Immediate problems that remain on my TODO list include:

1. We need a splash screen and icon.
2. Can we detect no network connection?
3. Reorienting the device messes with the page’s natural size.

jQuery.load and Caching

We have several places in our code where we retrieve content from the server with a jQuery.load() call:

var params = {
  'user_id' : userid,
  'category_id' : curCategoryId
};
$("#parent").load(url, params);

I was finding that after adding posts, new content failed to show up. It appeared that load() wasn’t being called.

A bit of investigation revealed that load() was being called, but jQuery first looks for the response in a cache keyed on the URL and parameters. To prevent these cache hits, one solution is to make sure not to repeat keys. We can’t switch the URL, but we can add a dummy parameter that is guaranteed to be unique for every call—like a clock reading. The server can simply ignore the parameter.

var params = {
  'user_id' : userid,
  'category_id' : curCategoryId,
  'nocache' : (new Date()).getTime()
};
$("#parent").load(url, params);

There are other ways to fix this problem.

Register callbacks on the unborn

Our posts page shows all the posts in a particular category. When we add a new post, the posts page gets a button/link to the new post. However, clicking on the button wasn’t taking me to the new post. That’s because we were registering the click event handler via jQuery.bind, which looks at the current DOM and hooks up the event only to nodes that currently match the selector. In our case, our new button didn’t yet exist when the bind() call executed.

jQuery provides several ways to hook up event handlers to nodes that come along in the future. My solution was to use $(parent).on(event, selector, handler). The parent node retains the parameters so that when future objects get added to it, the parent provides all the information needed to register the callback.

$("#menu").on('click', ".button", function () {
  curPostId = this.name;
  $.mobile.changePage("#post");
});

Returning parseable results

So far, we’ve used PHP scripts to formulate HTML content that the client needs to insert into the DOM. It’s been a simple matter of echoing the pieces out and using $(‘#target’).load to insert the response.

However, our PHP scripts occasionally return compound data that isn’t just inserted into the client pages. For these situations, I’ve been making a JSON structure in PHP:

$json['result'] = somefunc();
$json['path'] = sprintf('%s/images/%s.jpg', $user, $image);
echo json_encode($json);

On the client, I can call the PHP script with jQuery.getJSON, which parses the response using jQuery.parseJSON and yields a JavaScript object:

$.getJSON(url, function (data) {
  console.log(data.result + ' -> ' + data.path);
});

I have created the home screen you see when you log in/open the application (with four options: My Web, Everyone’s Webs, Questions for the Community, and Need Help?) and the My Web screen with dummy icons. I used the My Web screen Chris first built to build this version, but modified it so there was a little more spacing between the options/categories. I incorporated the “Web” theme with a spider web background and a spider icon, but we can scrap these if they are too much. I also included colors from Heather, with the dark gray background for the option buttons, light yellow text, and salmon colored borders if the category has a new post (demonstrated on Photos and Travel, but not actually implemented to reflect whether they have new posts just yet). There is also a login page that I started to create, but it doesn’t actually authenticate yet. Below are images of the screens, which are located in my local repository on the projects drive (P:\JOHNCH_10-15-2013\repo_hm\awc_hannah\client) in a file called home.html (and also pushed to the repository):

Home Screen:

My Web Screen:

DROP TABLE aphasia_comment CASCADE CONSTRAINTS;

DROP TABLE aphasia_post CASCADE CONSTRAINTS;

DROP TABLE aphasia_category CASCADE CONSTRAINTS;

DROP TABLE aphasia_user CASCADE CONSTRAINTS;

CREATE TABLE aphasia_user

(user_id NUMBER(9) PRIMARY KEY,

username VARCHAR(30) NOT NULL,

password VARCHAR(30) NOT NULL,

user_first_name VARCHAR(30) NOT NULL,

user_last_name VARCHAR(30)) NOT NULL;

CREATE TABLE aphasia_category

(category_id NUMBER(4) PRIMARY KEY,

category_name VARCHAR(30) NOT NULL);

CREATE TABLE aphasia_post

(post_id NUMBER(9) PRIMARY KEY,

user_id NUMBER(9) NOT NULL,

post_title VARCHAR(50) NOT NULL,

post_date DATE NOT NULL,

category_id NUMBER(4) NOT NULL,

post_image_address VARCHAR(100) NULL,

post_video_address VARCHAR(100) NULL,

post_text VARCHAR(100) NULL,

CONSTRAINT aphasia_user_id_fk FOREIGN KEY (user_id) REFERENCES aphasia_user(user_id),

CONSTRAINT aphasia_category_id_fk FOREIGN KEY (category_id) REFERENCES aphasia_category(category_id));

CREATE TABLE aphasia_comment

(comment_id NUMBER(9) PRIMARY KEY,

post_id NUMBER(9) NOT NULL,

user_id NUMBER(9) NOT NULL,

comment_text VARCHAR(100) NOT NULL,

CONSTRAINT aphasia_post_id_fk FOREIGN KEY (post_id) REFERENCES aphasia_post(post_id),

CONSTRAINT aphasia_user_id_fk FOREIGN KEY (user_id) REFERENCES aphasia_user(user_id));

INSERT INTO aphasia_category (category_id, category_name) VALUES(1, ‘My Event’);

INSERT INTO aphasia_category (category_id, category_name) VALUES(2, ‘Living with Aphasia’);

INSERT INTO aphasia_category (category_id, category_name) VALUES(3, ‘Family and Friends’);

INSERT INTO aphasia_category (category_id, category_name) VALUES(4, ‘Photos’);

INSERT INTO aphasia_category (category_id, category_name) VALUES(5, ‘Videos’);

INSERT INTO aphasia_category (category_id, category_name) VALUES(6, ‘Hobbies’);

INSERT INTO aphasia_category (category_id, category_name) VALUES(7, ‘Travel’);

INSERT INTO aphasia_category (category_id, category_name) VALUES(8, ‘Pets’);

INSERT INTO aphasia_category (category_id, category_name) VALUES(9, ‘Question’);

INSERT INTO aphasia_user (user_id, username, password, user_first_name, user_last_name)

VALUES(1, ‘millerhj’, ‘bleep’, ‘Hannah’, ‘Miller’);

INSERT INTO aphasia_user (user_id, username, password, user_first_name, user_last_name)

VALUES(2, ‘buhrhr’, ‘bleep’, ‘Heather’, ‘Buhr’);

INSERT INTO aphasia_user (user_id, username, password, user_first_name, user_last_name)

VALUES(3, ‘johnch’, ‘bleep’, ‘Chris’, ‘Johnson’);

INSERT INTO aphasia_user (user_id, username, password, user_first_name, user_last_name)

VALUES(4, ‘morriscm’, ‘bleep’, ‘Mike’, ‘Morrison’);

NOW We are using a MySQL Database, so I updated the script for MySQL and added the tables/attributes/properties we talked about in our meeting:

DROP TABLE IF EXISTS aphasia_comment_read;
DROP TABLE IF EXISTS aphasia_post_read;
DROP TABLE IF EXISTS aphasia_comment;
DROP TABLE IF EXISTS aphasia_post;
DROP TABLE IF EXISTS aphasia_category;
DROP TABLE IF EXISTS aphasia_user;

CREATE TABLE aphasia_user
(user_id BIGINT AUTO_INCREMENT PRIMARY KEY,
username VARCHAR(30) NOT NULL,
password VARCHAR(30) NOT NULL,
user_first_name VARCHAR(30) NOT NULL,
user_last_name VARCHAR(30) NOT NULL,
user_is_locked BOOLEAN DEFAULT FALSE NOT NULL,
user_image_address VARCHAR(100) NULL);

CREATE TABLE aphasia_category
(category_id BIGINT AUTO_INCREMENT PRIMARY KEY,
category_name VARCHAR(30) NOT NULL,
category_is_public BOOLEAN DEFAULT TRUE NOT NULL);

CREATE TABLE aphasia_post
(post_id BIGINT AUTO_INCREMENT PRIMARY KEY,
user_id BIGINT NOT NULL,
post_title VARCHAR(50) NOT NULL,
post_date DATE NOT NULL,
category_id BIGINT NOT NULL,
post_image_address VARCHAR(100) NULL,
post_video_address VARCHAR(100) NULL,
post_text VARCHAR(100) NULL,
CONSTRAINT aphasia_user_id_fk FOREIGN KEY (user_id) REFERENCES aphasia_user(user_id),
CONSTRAINT aphasia_category_id_fk FOREIGN KEY (category_id) REFERENCES aphasia_category(category_id));

CREATE TABLE aphasia_comment
(comment_id BIGINT AUTO_INCREMENT PRIMARY KEY,
post_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
comment_text VARCHAR(100) NOT NULL,
CONSTRAINT aphasia_comment_post_id_fk FOREIGN KEY (post_id) REFERENCES aphasia_post(post_id),
CONSTRAINT aphasia_comment_user_id_fk FOREIGN KEY (user_id) REFERENCES aphasia_user(user_id));

CREATE TABLE aphasia_comment_read
(comment_read_id BIGINT AUTO_INCREMENT PRIMARY KEY,
comment_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
CONSTRAINT aphasia_comread_comment_id_fk FOREIGN KEY (comment_id) REFERENCES aphasia_comment(comment_id),
CONSTRAINT aphasia_comread_user_id_fk FOREIGN KEY (user_id) REFERENCES aphasia_user(user_id));

CREATE TABLE aphasia_post_read
(post_read_id BIGINT AUTO_INCREMENT PRIMARY KEY,
post_id BIGINT NOT NULL,
user_id BIGINT NOT NULL,
CONSTRAINT aphasia_postread_post_id_fk FOREIGN KEY (post_id) REFERENCES aphasia_post(post_id),
CONSTRAINT aphasia_postread_user_id_fk FOREIGN KEY (user_id) REFERENCES aphasia_user(user_id));

INSERT INTO aphasia_category (category_id, category_name)
VALUES(1, ‘My Event’);
INSERT INTO aphasia_category (category_id, category_name)
VALUES(2, ‘Living with Aphasia’);
INSERT INTO aphasia_category (category_id, category_name)
VALUES(3, ‘Family and Friends’);
INSERT INTO aphasia_category (category_id, category_name)
VALUES(4, ‘Photos’);
INSERT INTO aphasia_category (category_id, category_name)
VALUES(5, ‘Videos’);
INSERT INTO aphasia_category (category_id, category_name)
VALUES(6, ‘Hobbies’);
INSERT INTO aphasia_category (category_id, category_name)
VALUES(7, ‘Travel’);
INSERT INTO aphasia_category (category_id, category_name)
VALUES(8, ‘Pets’);
INSERT INTO aphasia_category (category_id, category_name)
VALUES(9, ‘Question’);

INSERT INTO aphasia_user (user_id, username, password, user_first_name, user_last_name)
VALUES(1, ‘millerhj’, ‘bleep’, ‘Hannah’, ‘Miller’);
INSERT INTO aphasia_user (user_id, username, password, user_first_name, user_last_name)
VALUES(2, ‘buhrhr’, ‘bleep’, ‘Heather’, ‘Buhr’);
INSERT INTO aphasia_user (user_id, username, password, user_first_name, user_last_name)
VALUES(3, ‘johnch’, ‘bleep’, ‘Chris’, ‘Johnson’);
INSERT INTO aphasia_user (user_id, username, password, user_first_name, user_last_name)
VALUES(4, ‘morriscm’, ‘bleep’, ‘Mike’, ‘Morrison’);

Here is a potential database model for our Aphasia Web app.

I updated this model based on what we said during our last meeting (adding post/comment read tables, date for comments, user is locked and user image address attributes). I also added a category is public attribute because Heather would like the functionality for a whole category (diary) to be private.

Updated database design

So…Heather and I met this evening to work on finishing our story board that we worked on this past week. However, Heather met with Dr. Heopner this morning and they decided the application should be less “linear,” or really less like Facebook’s timeline, with too much on one screen. We had also had this concept of dating the entries for the my story section to mark when in the past things happened, but now we decided it would be too much drain on their cognitive abilities for this fairly insignificant detail (we had questioned putting it in in the first place, but decided to put it in so it could put their story into chronological order). Heather also hadn’t felt completely comfortable straying away from the ideas of having category/topic tiles to keep the application more organized and slightly more intuitive. She felt the “Community Conversations” module we decided on wasn’t natural enough for actually starting conversation. Therefore, from their meeting today, we decided to move towards users having their own “web.” In their web, they have their event, living with Aphasia, family and friends, pets, travel, photos, videos, and hobbies. Then they can add entries/posts within these modules, on which others can comment and such, because the users would then be able to look at the other users’ webs. From this stemmed an idea for the name of our application: Aphasia Web..! It reflects being a computer application (maybe web-based?), a social networking site for individuals with Aphasia, and the theme of the application!

Some questions we were left with after our discussion of this redesign (which we’ll describe more in detail in our meeting tomorrow):

1. Flexibility of adding modules? Which modules to have?
2. Flexibility of adding entries/posts?
3. Design within the modules?
4. Family tree?

We (Heather, Chris, Mike, and I) first met Wednesday, September 5th. On this day, Heather explained to us about Aphasia and the different types and how it affects those individuals in their ability to communicate. We also discussed how they view Facebook and some of the difficulties they have with the site (business, verbage, inability to communicate, etc.). We then stated that our main goal is to develop a social network application for individuals with Aphasia that is very clean and simple to use. From here we launched a little bit into a discussion of potential technology to use for the app, and JQuery Mobile and Phone Gap were mentioned. Some features we “spit-balled” for our app include: pictures, voice input, predictive text, topic indexing. Chris’s takeaway was to figure out how to upload a picture using JQuery Mobile.

Later on Wednesday, Chris and I met to go through the steps of setting up an Android app for my smartphone, including all of the installs necessary. However, for some reason I can never seem to make installs go smoothly, and this proves to be the case once again. I will have to come in and ask Chris’s help in getting my laptop set up for Android app development.

Heather and I met the next day (Thursday, September 6th) to discuss the project more. In this meeting, we talked about how, in general, those with Aphasia are usually 50 years of age or older, and most don’t have email accounts, so when they try to get them on Facebook, they first have to go through the steps of creating them a gmail account before they can get them on Facebook. We also talked about how logging in is an issue and it would be nice to find an alternative.

In trying to decide where to start, we were looking at a person’s profile page on Facebook with the whole site loaded and filling up the whole screen. I was looking at the page and realized that no matter how we change the verbage to try to make the site more intuitive (since a big issue is the language used, i.e. what’s a wall? what’s a status? what does it mean to post on a wall? what happens when you hit Comment?), the site will still be extremely busy and overwhelming for an individual with Aphasia. Then I proposed, what if when they logged in, they saw a screen saying, for example, “Would you like to edit your story today?” with Yes and No options. If Yes, it could bring them to a screen for editing their story, but if No it could bring them to another question, “Would you like to …” with specific choices. The idea would be to organize the site in such a way that it would be a guided experience for the individual using it, and then they only have to make one decision or do one thing on each page instead of having the ability to do everything all at once (like in Facebook where on every screen there is so much you can do: Like, Comment, Post, Photos, etc.). Heather loved this idea because she said it is very similar to how they do therapy, they ask a question and give options for the person to choose from to answer, and then based on that answer they ask another question and give more options and so on. Therefore, this guided approach would be taking a proven therapeutic technique and applying it to our social networking app!

We ended our meeting by writing out what we wanted to figure out from Heather’s focus group. We wanted their input on Facebook, what they like about it, don’t like about it, what features they use or would like to use if it were easier, etc. We also were concerned about how they would feel about privacy. Would they feel comfortable sharing their story with everyone or only people they knew? And on this note, would we include the concept of friends in our app, which is kind of the point of a social network? Lastly, we wanted feedback on our guided design.

Heather and I met again Tuesday, 9/11 to discuss how the weekend went at her Aphasia camp. She said it went great and she got some really good feedback. She had the chance to discuss our ideas with her mentor Dr. Jerry Hoepner, and he really liked the guided approach. However, he felt that if we could tie a realistic story to the experience, like discussion around a water cooler, then it would be even better because the individuals could apply the experience to a real life experience and it may make more sense to them. Heather also gathered that multiple modes of communication will be extremely important in our application. The key is that they want/need to be able to express themselves, and we need to give them the ability to do so in the channel that works best for them. Some are better at writing, some better at speaking, some at drawing, so if we have capability to include video, writing, images, speech-to-text, drawing, etc. then everyone should be able to find some way of expressing themselves. Lastly, we discussed the concept of having a password, and Dr. Hoepner’s idea was to have a keypad of icons instead of numbers so the individuals would just have to remember a correct sequence of three icons, or so.

We all met again the next day, Wednesday, 9/12 where we talked about our progress from the previous week and Heather’s findings from the Aphasia camp (what we talked about Tuesday). Chris showed us his ability to upload a picture using JQuery Mobile! We also decided that we should first work on a database schema, and aim to complete that by the end of the month.

Heather met with her focus group in Madison this past weekend. She documented her findings and intends to share them with us tomorrow!