Innovation Incubator: First Blood, Part Deux

Thank you all for a wonderful conference call last night. We made some important decisions:

We agreed to adopt the name VoxPop instead of Better Letter to reflect the various capabilities built into our innovation.

We will have a new logo to reflect that change

Brian and Heather will be our presenters in Toronto.

We will finish working on the presentation scripts and power point this week.

Prof Greg joined the conference call. He will work with his programming team to streamline the prototype.

Thank you again for your participation and for the great ideas. You rock!

The prototype looks pretty good right now.. For anybody who hasn't been linked, you can find stage 1 of the prototype here. The back end is located here.

Here are the comments that have been thrown around so far..

Tina noted:

-need a better font (maybe Helvetica or Arial)
-better design of "Better Letter" header
-coordination/incorporation of color
-text box for writing the letter is too small
-when ready to write message/upload content, it gets the user lost
-possibility of a text editor or way to upload a Word file
-the form layout is inconsistent
-on the View Letters screen: there should be a break after the
introductory paragraph
-validation code is confusing
-static back and forth buttons
-pop-up should be resizable

A few thoughts that I had:

-Use VoxPop instead of Better Letter from now on
-Put "back" button at top of window
-Maybe create a bunch of icons and let them sit near the top
-A small description of VoxPop on the splash screen
-New logos and buttons

Any others? I'm going to get cracking this weekend on redesigning the logo/icons/other buttons. When can we finally get a conference call with the programmers?

Because I know this has been a point of question, this is what embedded video looks like:

Though this video is "on" this web page, the resources for hosting it are provided by YouTube.

Here are some thoughts to consider, particularly now as a coder begins:

1) Before our second Ithaca trip, we hit on another name for Better Letter, which seemed to be a little catchier: VoxPop. We would have rebranded if it hadn't been three days out from Ithaca. Now seems now is the appropriate time to do this.

For anyone who doesn't know: In Latin, Vox Populi, means literally, "the voice of the people." Politicians used the term to refer to the collective power of the vote, which was wise not to disobey.

VoxPop seems appropriate for a pop-up based application that aggregates the voice of the people, and is a little "webbier" to boot.

2) I'm not pro or con video/audio/images, etc., but I would say we will enlist the greatest number of adoptors if we make this as modular as possible. That way, we don't shut out anyone who doesn't have the bandwidth/storage space/processing capability to host video, and we don't shut out anyone who does.

I've talked to Chris Raine about the fact that we really need to invest some time into our presentation with some "possible uses" slides. Maps, video, audio, comments sections; we've had a tremendous number of fantastic ideas, but we do a less fantastic job of sharing them with our audience.

3) The functionality of this program is really in the backend, i.e., a server that aggregates the contact data and the user/letter data. If we do not have a solid backend prepared when we go to Toronto, it is likely that each organization will have their own in-house programmers build one, thus defeating a major benefit:
A national standard for this data that can be shared and data-mined will never be achieved.

Essentially, without the proper steps taken initially, creating any sort of national or regional map-based information will be nearly IMPOSSIBLE.

Now is the time to set this on the right path.

I've spoken to the head of our news information track about the possibility that KU could host a server that would provide this functionality, and he was quite receptive. This is not a large investment; wouldn't it be great if K-State could house a similar server, and together, the fruits of this project would be hosted at our two schools?

It seems like quite a legacy for us to leave. It takes nothing more than a little upfront planning.

The only thing that concerns me now is that a team of programmers is going to start working on building something without knowing the full functionality that is desired. Sort of like hiring a deck-builder and saying "Build me a deck!" without any other instructions or parameters.

We all now the pains that occur when we undertake a task without a very clear idea of the desired parameters of the end-product. I'd hate for these programmers to have to discover the same pain.

Because it seems quite likely that any news organization will want to modify the appearance and perhaps even the interface of this program, coding the HTML is useful for our demonstration, but less so for adoption by news organizations.

In my opinion, we need an efficiently programmed server that can aggregate nationwide contact and user/message data, and provide it through a simple API, allowing news organizations anywhere to tap into the server, add information, retrieve contacts, and make meaningful use of the stored data.

This is no tiny task even for the team of coders at K-State, and so I think that it would be a fantastic project that they would be quite proud of. One that would, perhaps, have more longevity than an HTML frontend.

If this is achieved, I see us standing on the stage in Toronto, announcing, "And, by the way, servers are already established at KU and KState to share, store and transmit this information nationwide. Let us know if you'd like to access it."

This way, we can ensure that this information stays free and accessible to all nationwide. Awesome.

Quite naturally, I assume there may be some disagreement about these thoughts, but I'm interested in having a discussion.

Onward and upward, folks.

This week a team of coders at K-State will work on developing a prototype for us and we should be able to view and discuss it by next week. They will use the existing Better Letter HTML mockup as their starting point.

All,
I think I found a coder. I talked to the advisor for the MIS (management Information Systems) club, greg Smith. I explained our idea and he said he thought it was very do-able in 30 days. His only concern was not having someone to do PHP. Do we need that or can someone do the same thing in another language? Regardless, Sam is going to talk with him later today and hopefully get all this put together.

Can someone look into recording audio and what that would take to add to the application?

As for the petition, I don't think that's hard. If we have the option to read other letters, it should be easy to have the option to create/sign a petition.

Greg, from MIS, thought it would be pretty easy to add a mapping feature. They will have some good advice about how to do that.

As for the city council, they meet here in Manhattan every other Tuesday night. I'm not sure if they meet today, but one of us should find out and get down there with a video camera. But if no one can make it, maybe we can make an appointment to speak with the mayor and a couple of council members.

Heather

I am posting this for Sam:

Thanks folks for great presentations on Friday. We got pretty good and useful feedback on both projects. Regarding Better Letter, the
overwhelming response from our audience is that Better Letter is a
simple idea that fills a need and that they see this as something that
can be easily adopted by the media, especially at the local level. They
feel we should start courting local media instead of waiting to pitch
it to the Toronto audience. I agree. But we need a prototype.

I met a coder who is interested in helping us with our prototype. He
was present during our Friday presentation and liked the idea. He also understands HTML, Php, and MySQL. He will do it for a thousand dollars. I have sent an e-mail to Angela to see if we can split the cost with KU and I am waiting to hear from her. BUT keep talking to other coders so we can pick the best from the pool. I hope to have this sorted out by the end of the week so the coder can start working on it. We don’t have much time.

The written feedback from our Friday presentation is pretty good. Here is a list of some of the suggestions we received to help improve our Better Letter project:

(1) That we should think of a better way of identifying users to make
sure the innovation is not misused by the same vocal people (safeguard against nuts).
(2) Consider grading responses from politicians/public officials
(3) What do you do when response to an issue is overwhelming, especially at the state and national levels? (Address issues of scale)
(4) Make it possible for users to add their name to a letter/petition
that may be circulating
(5) Try and approach public officials in Lawrence and Manhattan and get their feedback on Better Letter
(6) You can add to that list our earlier suggestions that we need to do
some research and find out the best ways to incorporate video, voice
and Google maps to our project.

The best way to do these things (effectively) is to assign
responsibility and set some benchmarks (XYZ volunteers to do a
particular task by a certain date). So here is my suggestion: Let's
look at the above suggestions and discuss them on this blog. Once we have agreed on which ones to incorporate, then we assign duties and deadlines. Thank you.

--Sam Mwangi

Hello everyone!
I sent an e-mail to Stacy Smith of Disability Support Services here at K-State. I am going to copy and paste our e-mail back and forth. WARNING: This is an incredibly long e-mail, but it brings up many useful points, so it's worth reading
Cheers!
Heather

Heather -

Wow; lots of questions! First, thanks for considering students with
disabilities. Second, let me see what I can do on the rest.

I think I have a basic handle on what you are trying to do: essentially
to provide an interface for people to be able to use the web page to
send email; make, store and link to videos; and possibly to call public
figures on the phone?

I believe that there are two separate issues at work here with regards
to disability. Let me try to answer them individually.

First, the web site you are building should be accessible in and of
itself. The web site is the user's access to the content you're
wanting him or her to use, and if the site itself isn't accessible, it
won't matter what you do with anything else.

Think of it in these terms: you're going on vacation and you've found a wonderfully accessible hotel. If you can't drive the car because the
CAR isn't accessible, that lovely accessible hotel isn't going to do
you a bit of good.

Fortunately, making web pages accessible requires a combination of good web design sense and good code. All of the information on this is freely available and only costs whatever time it takes you to learn
what it is and how to implement it. Examples include: don't make
things flash/flicker (you can trigger seizures in some people). Always
use alt text to describe important images on your site, and if the
images aren't important, put in a null string (" ") so that speech
readers will ignore it. Don't use "click here" for your links - make
your link the document/page name instead. Make sure that changes on your web pages are always "announced" in some way - or in other terms, don't make any changes to the web page without telling the user. This means that newer programming practices such as AJAX may not work. Make sure the site can be navigated with a keyboard. This last may mean that some JavaScript controls have to be modified. For example, onMouseOver does nothing if you're using a keyboard. Have you noticed that some sites have a "go" button next to a drop-down list that you have to click before the new page will load? This is an accessibility thing - instead of using JavaScript to load the new page when the user releases the mouse button, the user must deliberately click a link.

K-State has some good pages that can help with these basic things, and there are tons of good resources out there from other entities. I've pulled together some resources (including the K-State links) on a page that you might find helpful:
http://www.k-state.edu/dss/k-access/web_page_accessibility.html

Second, on to the content - the bells and whistles. First, the variety
of tools that you plan to offer is very nice, and the good news is that
by offering a variety, you reach a wider range of people. A deaf
student can write an email OR make a video - you might be surprised how many video blogs are out there with people signing. Many students with mobility impairments will be fine as well. Since you are about creating content - not about being a repository for content - then you don't have to worry so much about captioning or providing text transcripts.

The tricky part comes in when your user is blind and uses text-to-speech software or has an impairment that requires navigating the site using speech recognition software. Let's start with text-to-speech.

Text-to-speech, or screen reading software, relies on the structure
within your site's code to "know" what to read and how to read it.
Navigation is generally entirely keyboard-based and relies heavily on
the tab key and many keyboard shortcuts. If elements are not coded
properly - for example, if form fields don't have labels assigned to
them - then the screen reader will not "see" anything and will not be
able to tell the user what's going on. Imagine trying to fill out a
form with your eyes closed....but when you tab to the next field the
computer says "text box" but you don't know what's supposed to be *in* the text box. Text-to-speech readers are exactly why your site
shouldn't do anything that isn't "announced" (like pop up a new window) - the user can't see it and therefore doesn't know anything happened.

Some programs are more friendly to text-to-speech software than others. Most email programs will work fine....except Webmail, which only works halfway. A good rule of thumb to start off with is this: do NOT override a browser's default settings or behavior. The screen reader software is built on those default behaviors being there. Changing them is bad design and will lock some users out of your site.

Speech-to-text users rely on their voice to manipulate software (open, close, open menus, etc) and to dictate text. Users may have mobility impairments that limit or prohibit their use of a mouse or keyboard. Again, you want to make sure that the software you're using will work with these programs - the most popular is Dragon Naturally Speaking. Whether or not your software will work with Dragon would be an excellent question for the folks at Nuance, who have a technical support team.

I might suggest that you offer people the option of recording video OR just recording audio. Some people - disabled or not - want to be heard but aren't so keen on being seen.

Now - as for the cost and difficulty questions, I have no idea. Those
questions are better answered by vendors or groups that are working on that particular software and/or in that particular application. Check out the Skype webpage, for example, for accessibility. The Yahoo JavaScript library has a whole accessibility initiative. There are
TONS of good people out there who will be very excited to learn that
you're thinking about accessibility up front and who will bend over
backwards to help you. When you have specific questions about software and/or applications, I may be able to put you in touch with specific people who have better advice. Let me know when you get to that point.

Thanks, and good luck!

Stacy

Thanks to Sam for remembering Wired's five-year anniversary article on the creation of the iPod, which validated some of our own experiences (and thoughts) about the innovation process. One of our joking mantras throughout this process has been, "Whatever we do, it can't suck." Then we saw this gem in reference to Anthony Michael Fadell, a lead designer on the iPod:

Only after agreeing did he learn that the job was to put together an MP3 music player that would work with Apple's existing iTunes application and would not suck.

At the Ithacan conferences, we heard several times about how the creation nets process helped develop the iPod. Something important that should be pointed out is:

There is no single "father of the iPod." Development was a multitrack process, with Fadell, now on staff, in charge of the actual workings of the device, Robbin heading the software and interface team, Jonathan Ive doing the industrial design, Rubenstein overseeing the project, and Jobs himself rubbernecking as only he could. For specific tasks, Apple drew on experts working elsewhere in the company. Fadell also contracted with key outsiders, notably a San Jose company called PortalPlayer and a small firm of Apple expatriates called Pixo.

The net built by Apple wasn't just an ad hoc team thrown together, it was a targeted group of experts who were all aimed at a single, pre-established goal. Finally, those experts didn't go into the process with a goal of changing the world, only building a really good music player.

No one mentioned that this product might transform Apple and set the technology world, the business world, and especially the music industry on their heads. Because no one suspected it would.

Hello all!
This week has been a little crazy for all of us. As for the presentations next week, I agree we need to get together and revise them. Definitely on our Novus idea. K-Staters, can we meet up this weekend or next week to work on our presentation? I kind of thought KU would present Better Letter the way it was in Ithaca, and then leave a little time for both groups to discuss the changes we are working on now. Does this sound like a good idea?