As a rising sophomore at Duke University and a web programmer, I was naturally excited to see the update to our new Automated Computer Enrollment System (ACES). However, upon seeing the update, I was quite disappointed to say the least. Not to add to the moaning and groaning coming from plenty of my classmates, but I’d like to make a few technical points about this supposed upgrade. First, why PeopleSoft 9? It was released two years ago, which in web development is a long time. Additionally, from what I have read, it was known for its security, which I had believed was the point of Shibboleth in which case there was no need for PeopleSoft. Partially as a result of it being so old, it uses horribly inefficient, old web development styles. There is no AJAX at all anywhere on the site, nor many iframes. Rather, the site is a few large frames and nearly every click requires a full page load - as a matter of fact almost every link is a full form submit. And, simply as a matter of design, it is heavy and ridiculously inefficient to navigate. To get to anything takes numerous unnecessary clicks and page loads; and there is no one definitive place to do any specific action - enrolling can be done in two DIFFERENT locations that look nearly identical, so I ask - why two spots then? And, of course, Duke didn’t set it up quite right yet so as a result most classes are displayed with sections and times from old years. To say the least, it is a mess and essentially unusable.
As I have done before, I would like to ask Duke to push the envelope on this project. The administrators have on their hands literally hundreds of students who clearly care about this system, viewing the site within the first 24 hours of it being released and posting their opinion eagerly on their Facebook status, creating the Facebook group, and e-mailing the registrar. Both I and a rising Junior independently created webpages to build a graphical schedule despite the old system being lost, and another one of my friends told me that he was planning on doing the same thing, and now planning on helping me out to enhance mine. Without a doubt students and teachers, want things to change and apparently are willing to put at least some thought and time into it. However here is the killer, there are too many hurdles. In the three days that the link to my schedule generator has been posted on Facebook there have been 125 visits and 160 pageviews, but only 56 graphical schedules actually generated. Why? It is a simple flaw of my site, it is pain, god knows how many clicks, to actually download the iCal file and upload it to my site as compared to the simple old system of refreshing a single page. So here is what I would like from Duke - LET us help out, just do the one thing we can’t, take down the barriers. Make a system for us to easily access a logged in user’s data and customize the way its displayed, let us take all of the data for all of the classes and create our own systems of searching and testing out schedules - neither of these tasks seem to be much of a privacy concern. My friend Nick Bottenus created a system for testing out different schedules, but again it could have been far more effective if it had better site integration. Hell, even allow students to choose other interfaces for registering for classes; take some of that load off of your servers that manage to nearly be brought down to a halt each semester on those splendid 7 AM morning rushes, always nearly as chaotic and clearly effective as the free Homecoming t-shirt give away this year. Use the internet to its strengths, and likewise the students, and prove that Duke is a place of innovation, action, and on the forefront even in class registration. Having a development platform for class registration, now there is something different I didn’t here on a college tour. Administrators, you have it easy, an open opportunity. There are willing and able students who want to help, all you have to do is let us.
Update: Nick Bottenus and I have created a new version of the schedulator, enjoy: http://dukesched.ambmediadesign.com/.
Tags: Duke
In the seemingly never endless wait yet quickly approaching wake of the Facebook redesign I decided I should update my Greasemonkey Quick Links script. Unfortunately, hacking this new version of Facebook was not quite as simple as appending some HTML to a div. Because of Facebook's push towards more AJAX integration, even their menu system is far more Javascript than CSS dependent and now requires running a few of their functions to add event listeners appropriately for new menus. Because this seemed like a bit of work, I decided to make a nice clean function that others can use should they want to make their own menus in Greasemonkey. The full new Quick Links script can be found here. The function to add a menu is below or viewable as its own file.
JavaScript:
-
/*
-
This method adds a new menu to the top menu bar
-
string title - The title of the menu
-
hrefs - array of strings that contains the URLs for the menu items
-
links - text to be displayed for the link. if you would like a menu seperator, pass '<hr />' as the string
-
*/
-
function buildAndInsertMenu(title, hrefs, links)
-
{
-
var cond = title.replace(" ", "_");
-
var menu = document.createElement('div');
-
var html = "";
-
menu.id = 'fb_menu_'+cond;
-
menu.setAttribute('class', 'fb_menu');
-
html += "<div class=\"fb_menu_title\"><a href=\"#\" id=\"nav_" + cond +"\">" + title +"</a></div>";
-
html += "<div id=\"fb_menu_" + cond + "_dropdown\" class=\"fb_menu_dropdown hidden_elem\">";
-
var i;
-
for(i = 0; i <hrefs.length; i++)
-
{
-
if (hrefs[i] == null || links[i] == null)
-
continue;
-
if (links[i] == "<hr>")
-
html += "<div class='fb_menu_separator'></div>";
-
else
-
html += "<div class=\"fb_menu_item\"><a href='" + hrefs[i] + "'>" + links[i] + "</a></div>";
-
}
-
html += "</div>";
-
menu.innerHTML = html;
-
if(document.getElementById('fb_menubar_core') != null)
-
document.getElementById('fb_menubar_core').appendChild(menu);
-
var dropdown_id=menu.id+'_dropdown';
-
var menu_anchor=menu.firstChild.firstChild;
-
if(typeof dropmenu == 'function')
-
hover_menu(menu_anchor).registerHTMLMenu(dropdown_id).setPosition(dropmenu.ALIGN_LEFT).setTimeoutInterval(objMenubar.timeout).addHook('show',bind(objMenubar,'_onShowCallback',menu_anchor,dropdown)).addHook('hide',bind(objMenubar,'_onHideCallback',menu_anchor)).initialize();
-
-
}
Tags: Facebook · Javascript · Programming
I was recently reading in the New York Times "As Web Traffic Grows, Crashes Take Bigger Toll", an article about the need for greater sustainability in Web 2.0 websites. The article provides interesting insight into the quickly growing costs of server outages for large companies like Amazon, Google, Twitter, etc.. With sites like Google Docs and Grand Central, the internet is quickly and undeniably becoming an integral part of nearly every aspect of the day. And, at the same time, there has been an increase in projects like Mozilla's Weave and Apple's new MobileMe, which aim to add an increased level of portability to internet use.
In coming years, the internet will no doubt play a larger role in our lives. The internet is quickly coming a greater part in previously stable services such as phone service, television service, and GPS. And, with new experiments such as smart homes coming closer to a reality and a commonality, the need for dependability is growing exponentially. Although not necessarily the main point of the article, the author raises an interesting question of what users can reasonably expect of web companies. "He [Jesse Robbins] says Web services should be held to the same standard of reliability as the older services they aim to replace." Robbins explains this making an analogy to the lights going out at Macy's. While this analogy makes sense for a site like Amazon, it underestimates the strength and possible pervasion of these new sites into everyday life. With sites like Grand Central and VOIP, the service being replaced currently has far better uptime than most websites; a clear challenge for these services.
To handle quick growth and increasing scaling issues, it seems that centralization and cloud computing have become staples of Web 2.0. This has become a commonality in a variety of online development forums. Hosting sites like Amazon's EC2 and Media Temple offering server storage "in the cloud" for start ups. Web applications which offer online storage like Google Docs, Zoho, and Flickr also continue to centralize data. And lastly, services like Grand Central and Google's App Engine have, for some, come to be necessary parts that support lifestyles and businesses. Clearly, the cloud has already begun being an integral part of our lives. However, is this for the better?
And now I come back to where I started, the article and Robbin's explanation of how much dependability we can reasonably expect. But, is it a matter of being reasonable? As economists know, rationality is decided by observing consumers behavior, not dictated to consumers. Likewise, reasonable expectations will only be a matter of how much consumers expect, not what scientists expect of servers and dictate to be reasonable. It is for that reason that the internet originally survived. It was decentralized and as a result, an outage in one server had minimal effects on the greater internet. For this same reason, BitTorrents have flourished. And, in case Google forgot, it is what makes indexing and searching so important - it permits and even encourages decentralization content to be accessed on a far wider scale.
While movements such as these have made for some great progress online, Web 2.0 seems to have lost the essence of the internet. And, if we don't change our ways, like the first bubble burst, the wrong falling cloud could easily seem like the sky is falling. Rather, I suggest up and coming technologies to change their ways. Technologies like Weave should not pull from the cloud all the time, but rather pull directly from other personal computers. As proven by the recent outage, Google Doc's new use of Gears for offline use is backwards; documents should be stored on the PC and backed up online for wider use. And, hopefully, there will be an increase in home servers. Only this kind of decentralization can offer wide spread dependability, scalability, and allow the internet to continue expanding in a promsing way that can encourage it to safely play a greater role in our lives.
Tags: Musings
I know I already posted about this subject once, but I must again express my disappointment in Adobe. After reading this post on Adobe's blog about their "cool new features" such as this embedable flash version of PDF's, I was again a bit surprised at their Adobe's simply silly buisness strategy. Adobe is clearly trying to keep up with a combination of services offered by Google Docs and Zoho with their Buzzword application and Scribd's iPaper with this PDF-flash widget. However, I find it both rediculous and unintelligent that Adobe is blatantly offering a sub-par service when trying to win over Web 2.0 users; it offers a small, buggy flash widget to compete with iPaper and leaves Flashpaper, a clean, simple solution, on the sidelines hoping to make money off the $100 charge for the software or hoping some host will fork over a good chunk of money to suddenly revive Coldfusion, starting at ground zero of this arena? One would think that in the face of serious competition to many of its services, it would throws its best into this new arena, and change the way they monetize their product as they have been doing with other services such as Photoshop Express. I would love to use this new embedable flash preview but it simply unrealistic. The quality is too low to read and can not even be enlarged to fit the web page appropriately. Adobe, make a smart move and bring Flashpaper mainstream, enable it for everyone, offer up some ads with it. Do this and I will gladly support and use this new project.
Tags: Programming · Web Development
So it is 10:51 on June 26th and of course I am waiting around to go see Wanted at midnight. Being the responsible consumer I am, I purchased 3 tickets for the showing 2 hours ago so as to make sure my friends and I had tickets before taking a single REM-cycle nap so I do not die getting up for 8 AM work tomorrow. And, like the trusty computer nerd I am, as I fell out of bed and stumbled to my computer in the dark, I refreshed my Facebook home page to see a popup from Fandango asking if I wanted to display that I bought tickets for Wanted. And, like a rational, typical American consumer that thinks after he acts and then realizes what he has done, I said sure, tell the world that I bought tickets to Wanted - hell it's going to be an awesome movie, and then I realized DAMN I forgot to even take a screenshot or click on the "Preferences" link. And now I sit here I am wondering, what in the world was that? As far as I know Facebook Beacon has been dead for nearly a year and a quick search on Google for Facebook and Fandango only pulled up articles from November of last year.
Unlike most of the posts from last November, I am not enraged at some sort of loss of privacy, not even annoyed that is on my Facebook Mini-Feed; it's kind of cool actually in light of the new commenting features. However, I am still at a loss of how Fandango was able to do this. As far as I've seen in the standard Facebook API, to at all interact with Facebook at least requires the user's approval of the application or website before the data is sent. Also, Facebook Connect is not out yet (unless that was Beta testing). And, although Facebook Beacon can still be found on the developer's website, there is no way to use it other than send Facebook an e-mail and hope for a response (which I did a few months ago to no avail). So, I am still a bit at a loss as to how Fandango has this privileged access into Facebook and more importantly - when can everyone else use it?
On a side note since I am posting this a day late - Wanted was awesome.
Tags: Programming · Web Development