WINK is a client-side plug-in that adds dynamic intuitive navigation and discovery interactions to normal everyday wiki environments, such as Wikipedia. Modifications and content exploration take place right within the context of the existing wiki page, without the need to switch to an arbitrary "edit" mode.
A large part of the inspiration behind WINK comes from the vast improvements that have been made in web based content editors and management systems. In just the past 4 years, the very nature of the way average users engage with what was once "static" content on the web has been completely upturned. Now, unlike ever before, users can edit documents and digital content from right within the very web page itself, with absolutely no technical knowledge required whatsoever.
Despite the massive success of such WYSIWYG editors such as the very wiki system I'm using this very moment, I still felt editing could be even easier. Current content editors require users to enter a different "mode" during the editing process. My goal was to provide a system in which the user could edit content right inline, further closing the gap between consumption and creation. It is this symbiotic relationship that I was most excited about exploring.
User InteractionEditEngaging with WINK is incredibly simple and powerfully intuitive, as it was designed for fast, engaging navigation. All a user has to do is simply roll over one of a wiki document's embedded links, and the helpful navigation menu instantly pops up next to the target embedded link, providing quick and intuitive access to relevant remote information and interactions.
In its current state, WINK consists only of a simple client-side script (called WINK.js) that is easily embedded within the HTML document. The script handles the modification of each outbound link within the wiki page's content and makes extensive use of the powerful jQuery library to increase browser cross compatibility and simplified much of the code..
The actual wink script is super lightweight and makes use of jQuery's DOM traversal / manipulation resources to modify the wiki document. A summary of the script's actions are as follows:
- Locate and wrap a element around each embedded link within the primary content block of the target wiki page
- Assigns a hover event over each element that inserts and deletes the quick-link text interface after each embedded link on mouseover and mouseout
- Assigns three sub-functions to each of the quick-link items
- Insert: pulls the content from the link's target wiki page sentence-by-sentence and easily inserts them into the containing paragraph
- Expand: pulls a larger chunk of content from the link's target wiki page; however, displays this text in a pulled-out content section where the user can either continue remotely surfing the target page's content or can choose to embed the text within the document
- Add: dynamically inserts a text form for the user to submit his own text into the very page of the document
Unfortunately, in its current state, WINK does not provide a very flexible framework for powering other similar interactions. It's treatment of the DOM is too specific to the Wikipedia context at the moment. With a few modifications regarding how WINK identifies embedded links, however, the client-side script could be extended to apply to a variety of wiki's with not too much effort. The largest difficulties, although, lie with the server-side implementation.
Evolving Documents: A Model for Interactive CollaborationEdit
As mentioned before, part of the inspiration for this project has been the vast potential that can be unleashed by bringing the two media use paradigms - consumption and creation - closer together into a symbiotic relationship that transforms the web from a collection of static documents to a more dynamic, "living" coagulation of thoughts, ideas, concepts, and creativity. It is this powerful dream that drives WINK's future reusability potential.
Wiki Platform ExtensionEdit
Ideally, WINK (or another interface package of the same vane) would be integrated nicely as a plug-in to existing Wiki platforms at all levels of organizations, from commercial systems to free utilities. The more ubiquitous the interface, the more content will be created, consumed, and modified - building powerful communities and vast new stores of knowledge.
WINK's future developments should focus on attempting to abstract the remote content search process from the actual display within the document. By keeping the interface to a minimum, but constant, three options (insert, add, and search), there is less worry that users will become confused by a potentially cluttered interface.
The insert method should be recoded such that it could potentially take a matching function as it's paramater as it queried the target document in search for the most relevant information to quickly add to the document. This function could take into account whatever parameters or context the implementer wished, allowing for a wide variety of engaging wiki navigations.
Unfortunately, WINK currently lacks a server back-end to feed the constant content requests that its natural interaction lends itself to. This functionality is paramount to the continued development and success of WINK or any other in-line editing tools. The implementation would not be too difficult as most wiki data is fairly compact (the entire English Wikipedia database if only 5 gigabytes, for example). Its compact size also means that it can be easily indexed and queried over, allowing for plenty of future developers to apply their database creativity to gain access to mountains of insightful data to feed the WINK system.
- Based on preliminary tests, the in-line interactivity WINK enables is not only powerfully intuitive but also generates tremendous excitement and engagement with new users. It takes only a second to notice the excitement in a user's face as they try out the insert functionality. They quickly begin testing out various words across the entire document, even words that they might have previously never have engaged deeper with.
- WINK's active use leads to mountains of new data and interactions. Because by definition, engaging with WINK means modifying documents, users often do not realize how greatly they've changed an existing document until they're deep into the process of consuming (and evolving its content).
- Limited data types: because of its inherent structure, WINK lends itself primarily to dealing with text data input and modification, especially with regard to a wiki environment. While it is incredibly agile in the context of a text heavy document such as a wiki page, not only does the simple text interface seem primitive next to other digital formats such as images or video but the paradigm of delving deeper into hidden content does not translate directly to embedded rich media. Plus, rich media formats require more system resources, and the quick nature of WINK's interactions would not lend themselves well to much heavy use.
- Sometimes full featured content editors inspire more users to make real, meaningful contributions to communities and websites. By decreasing the barriers to content-creation, there may be a deluge of "useless" data from unintentional use; however, by potentially aggregating changes across a variety of pages, valuable trend data should be able to be discerned regarding some interesting underlying data behaviors.
I'm incredibly happy that I decided to take this course, and it has been an amazing ride. Thank you.