Browsers vs. Application Environments and how that may affect privacy

I don't know if this blog is still being read or not, but here is my culminating post which results from a conversation I was having tonight...

Browers are obviously in a transitional phase between "browsers" and "application environments". Web-enabled applications (like email clients and so on) despite their more responsive interfaces seem to me to be declining in favor of the sheer convenience of web applications running in the browser. I'm one of the only undergrads I know who still uses an email client for my personal email, but even I am starting to use my gmail in a browser.

Another shift is the relevance of privacy. Many of these new applications rely on detailed usage data for functionality and monetization.

Web browsers are not designed to be application environments, and as such their responsiveness, usability, and power suffer, while development remains difficult.
It seems likely that one day web browsers will be more explicitly designed as application environments, although the questions of what will change will be extraordinarily difficult ones. Many of the benefits of current web applications could disappear if the application shift were poorly managed... total portability, no need to install, isolated in a "sandbox" from the computer, and more.

However, assuming that these problems were solved satisfactorily, having a more powerful system to build web applications could present an interesting compromise for privacy. Facebook's newsfeed relies intensely on both explicit and implicit behavioral data (as well as explicit preference settings, but those are less interesting) to filter the gargantuan feed into something manageable. Since most data is explicitly opted in to facebook - contact information, photos, etc. - this "underhanded" information gathering presents somewhat more of a privacy concern, especially concerns that this information will not be used only for usability but monetization. In a more powerful application environment however, this behavioral data could be collected and stored clientside, and the feed could be filtered on the client side as well. All facebook would need to do would be to push the continually updating algorithms and data-collection rules to the client.

Defining the walls between client and server would be tricky of course... Facebook could say they store that data on the client, but in a powerful application environment, it would surely have the ability to siphon off that data if it ever wanted to be sneaky. Practically speaking, this idea may be impossible to implement, but it's an interesting idea.

More generally... I can't wait until browsers get more app-friendly. I'm tired of my old-ish computer stalling for a second after I open the umpteenth google map and it loads all of that heavy javascript.

Client-side google

As the Open Past Midnight presentation mentions, it's hard to get google data into the database because all of the functions in the API are client side. We had been intending to implement a similar solution to what they did, but luckily discovered that google exposes its geocoding function through an HTTP request, which we can make from PHP.

Unpredictable Use Cases - An Exercise in Ambiguity

One of the trickier parts of developing an application is dealing appropriately with input and interaction that doesn't follow the exact model that you envision. In particular, we have to deal with "location" strings that may not map precisely to a location in google maps. Google maps does return an accuracy value to HTTP geocoding requests, but even when accuracy is low or the input is ambiguous, google will only return a single response. It would be great if we could present a "did you mean THIS, THIS, or THIS?" and show a map marker for each one, but we don't know if that's possible. So the best we can do is decide on an accuracy threshold that we will accept - we chose 4, which means that google can find the city, on the assumption that a person choosing to set their location will at least decide to specify their city. Ambiguity is still a major problem though - searching for "UCSD" is very ambiguous, and the top result that google currently returns is actually a location off campus. Currently we are just planning to reject such <4 inputs and request users to rephrase them or override the rejection, but if I get time before our presentation we will hopefully allow unknown locations to be added to our database (as mentioned in an earlier entry).

Object Oriented Un-Fun:why we dropped it

While our brief attempt to keep the interfaces between parts of the code straightforward using objects was a good idea, we ultimately dropped it for a couple of reasons. It was really slow - the nature of initiating and populating objects singly meant that when somebody had more than a few friends on the application it went realllly slowly, both for facebook's function calls (which are designed to operate on arrays of users to prevent this) and surprisingly our own mysql database... while the hosting is transparent to us, I guess the database may be hosted on a different server or even a different database from the server running our php code. The other reason is that making a globally-useful "friend" object just wasn't working out for us - the nature of developing a project with inexperienced users on the fast and on the cheap meant that we didn't know exactly what we needed/wanted and we were always changing things. When multiple functions are using the same object, it gets complicated. It turned out to be easier (on THIS scale - probably not on a larger or longer project) to just pass arrays between functions, because then we only had to manage the relationship between the functions that interacted.

Object-oriented fun

Kristine and I designed and are building a Friend class in our application framework that hopefully will make it much easier for other members of our group to contribute to the coding. We were concerned that the different learning curve shapes meant some members were getting left behind and not learning a lot. This class abstracts out the facebook backend plus our mysql backend, so all you need to do is create a

$person = new Friend(userId)

and then all of the things that are relevant about that person are available within php programmatically.

$person->getStatusMessage() will pull their current status message from facebook, while
$person->latitude() and person->longitude() will pull their locations from our mySQL database.

I suspect this will reduce performance - when we trying to display information for 10 friends at once, we will be hitting the facebook database/our database 10 times sequentially, rather than using their preferred array calls which get info for many users all at once (I did make it so all of the values get pulled from facebook at once, to at least somewhat limit the quantity of hits: if the desired member value is not yet set, it will call a member function to set all facebook values at once, and then if it is set, it will just display that value without talking to facebook again). However, performance is not what we're optimizing right now, right now we're just trying to make it a little easier to work inside our application framework.

Once again I'm learning practical uses of things I only had an academic appreciation for before... I've always "known" object-oriented programming, in that I created an object once in MAE 9, and knew that objects were containers for functions and variables. However, I've never really used it for a purpose, and now I'm excited at how useful objects are, how easy they make things.

Accessing GMaps javascript inside PHP

The integration hurdle I'm currently working on is accessing Google Maps javascript functions inside PHP. The reason Phoogle and the other wrappers I was able to find didn't cut it is they basically output javascript/html to the browser, they don't actually let php call the functions. They are very nice in accelerating the development of simple applications, but they don't truly re-create the GMaps API in PHP. What we'd like to be able to do is use getLatLng for the location the user enters and store that in the database, or let them choose a location if getLatLng isn't able to find anything for what they've entered.

The solution that I've come up with is to use AJAX - the page we're making the call from sends the user-entered location to another PHP page, which generates the appropriate javascript to make the call and output the collected information as XML, which then can be read by the calling page.

For now, I'm not really sure if I can implement that. Given the unpredicted constraints in learning curves and availability I've had to largely take over development of the GMaps portion of our application, and it may simply be easier to send the raw strings entered by the users over to GMaps, and if it can find a latitude and longitude for them, great, if not, oh well. Data validation is great, but we work with what we can.

Using MapLink / draggable markers

I was able to talk today with Beth Surrell from Tritonlink, who is putting me in contact with the programmer who created MapLink. Interestingly, MapLink was built by a student who just recently got hired on to work full time for Tritonlink. I'm still waiting for the communications to filter through, but hopefully we can begin working on that part of it soon.

In class on tuesday the Google Maps presentation gave me a lot of new ideas about the ways we can use Google Maps in our interface. The draggable marker could easily be used for a person to set their location graphically, making data validation much easier. We can be relatively confident that the latitude and longitude of a GMarker is valid; with text input we need to run the geocoding function and check to see if we get lat/long values back. Potentially this could also be used for community geocoding: users type in something textually, and if we/google don't recognize the location, we can say "okay, find it on a map for us". Then they will drag the marker to the correct place on the map, and we can store that data in a separate table for the next time that user, or indeed any user wants to use that location.

Using FBML

I have been working alongside Kristine today, and she has been figuring out much of the FBML which makes it very easy to display information like profile pictures and names. All you need is the user id as an attribute on many of these fbml tags, and it will be able to generate (for example) the profile picture and name for a user, linked back to their profile. To implement this programmatically, we would need to call the users_getinfo function with username and fields as arguments, then fish the results out of the returned two-dimensional array. We do need to get some of this information programmatically to update the database, but luckily we can avoid much of this in designing the UI. On the google map for example, we hope to be able to put information such as the profile picture and status into an infobox for each point on the map. If we change our minds about how exactly we want it to look, we can manipulate the fbml much more rapidly.

The near future

Integrating with the google half of the application will be another hump, but luckily I have already specified what the interface would be: one string for the current user's location to center the map, and a 2-d array with [friend index][friend name, friend location, last update time] to plot friends. I have a little feeling that we should already start specifying interfaces for the more advanced functionality we have speculated on, but it is very difficult because we have to have a fairly specific idea of how it's going to work before we can specify the back-end interfaces. It is great to be future proof, but it is better to have a usable product TODAY.

Depending on whether or not our scheduling works out this week, we should be able to easily complete Round 1 of our development this week or this weekend. So, to make sure we have somewhere to go after that, I am going to be meeting with my friend Beth from Tritonlink tomorrow to see if we can make use of MapLink for the campus-level geography.

In the super-long-term, it is interesting to think about how this could be extended to other campuses, with community input of campus geographies (sort of how facebook started, with community input of available courses at each university and the like). That is far beyond the scope of this application however... if we are lucky we will get to use facebook's SMS functionality but that would be the farthest I see us getting this quarter.

Humps - education and integration

After an initial "where on earth do we start?" period we are proceeding very rapidly. Although it's important to keep up with what everybody in the group is doing, deciding to specialize has really helped us move forward by reducing the education burden. I'm handling the location-setting part of the facebook application and the back-end, so I have been able to focus pretty much entirely on learning php and mysql. I'm actually really excited about that, because I've been "learning" php for about a year and a half now, as in I have had a nice thick book on my bookshelf for a year and a half and have gone through the first 2 chapters about 5 different times. But now after just a couple of long nights trying things and misplacing semicolongs, I'm confident enough to hack around with the framework that I have up there already, and spend more time looking at the text editor than at google or the php book. Mysql had no hump to speak of - it's incredibly simple to write the queries, and since it comes with a very nice GUI it's a snap to update or change the structure when we decide we need to.

Now that the education hump is over we still have the integration hump to deal with. Kristine and I have been working separately on the two halves of the facebook/server side of the application in separate files just running on our own server; bringing our work together and putting it on facebook has been a tricky process and it seems like maybe we should have started that a little bit earlier. There are an assortment of niggly little things to deal with; for example, on my own server the action of the form transfers variables to another php page very easily, but on facebook it doesn't like leaving the callback URL so I need to figure out how to get multiple pages up or have the form be self-referential. However, the collaborative aspect of programming is very interesting - working side by side on computers and being able to instantly glance over and give tips and see what kind of code is happening is very effective. It's not quite "extreme programming" but it works pretty well.

Beginnings

Beginnings are hard. The beginning of the quarter is the hardest part for me, because I find it really difficult to ramp up my enthusiasm for a course. But I think I've managed to get it back on track now, having just submitted assignment 1, only... 4 days late.

It was really interesting restraining myself to use only HTML. I didn't make my first web page until long after CSS was the accepted standard, and it was awkward trying to do things in HTML that I really would have preferred to do in CSS. "Back to the basics" is almost never out of place.

I chose a topic that really interests me - maintaining engagement, within the specific context of UCSD. No, I don't mean engagement as in marriage, I mean engagement as in attention, but I choose to say "engagement" because it feels like a much more active word, just as we should all be active. UCSD has a reputation for being boring, antisocial, or dry, but this reputation is largely undeserved, and has its origin in the way those people parroting that line choose to interact with UCSD as a whole. Perhaps UCSD does not have a culture that sweeps people up and draws them into the fold, but that only means that we must choose to actively interact. I wrote my website for assignment 1 detailing some of the activities and ways of approaching college life have helped me to maintain engagement, and be excited about what I am doing.

I'm still drawing a blank for the project. In Cogsci 102C I remember bursting with ideas, because I was safe to play in the realm of the hypothetical. We didn't need to actually build our fantastic calendar system. Now I feel a little bit restrained by reality, and by the scope of the course (web programming, essentially). I am excited about what's available: Google APIs, Facebook APIs, Pipes, Flickr, and on and on, but all of this excitement is running up against a wall, because I don't know what I actually want to do. Hopefully this is just a mental block that will take care of itself soon enough!

Here I Am

Hello world!