Last week we wrote a 2-page paper about Access Lecture to try and get our poster accepted for the 2011 ASSETS conference in Dundee, Scotland. We always thought writing one of those long research papers would be difficult, but we found that our initial draft was almost 5 pages long. It turns out that it's really difficult to write about everything we've done when there's a limit of only 2 pages! ASSETS is a conference specifically dealing with accessibility and assistive technology so we're really crossing our fingers and hoping we get accepted.
After finishing the paper we decided to try making our zooming work with the UIWebView we were using to display the notes. We quickly learned that we needed to inject javascript into the website in order to enable increased levels of zooming. For pinching to zoom this worked fine, but when we tried using our code to programatically zoom via buttons, we encountered some problems.
When we were working with a UIImageView we were able to easily calculate the center point of the view and zoom in on that point. For some reason even though we are again calculating the centerpoint, the UIWebView only zooms in on the top left of the screen..additionally that are many quirky bugs that we didn't experience when working with UIImageViews.
We've posted on Stack Overflow and a couple of IOS development forums but so far we haven't received any responses. We think that we lack an understanding of the connection between the UIWebView and the UIScrollView that's built in; however, we haven't found any comprehensive explanations of that relationship. We're hoping that we can learn more about how they work together so that we can understand what's different about the two scrollviews. Right now the behavior of the webviews scrollview is very different than the behavior of the scrollview we previously implemented. Apple also makes it a little challenging to get access to the UIWebView's scrollview, which might mean that it's not intended for developers to manipulate it very much. Right now, it seems like that might be the case and that we're trying to do something with the webview that we're not supposed to. In our experiences so far, Apple typically makes methods private if they don't want you to use them for apps, but the fact that they don't supply an easy way to access the scrollview could also imply that we're not supposed to be meddling with it.
~Lindsey
Monday, June 27, 2011
Thursday, June 16, 2011
Pieces coming together
Hello all,
Just as our second week of 9-5 development comes to an end, our "proof of concept" implementation does as well!
We have worked towards one primary goal this week: Create an iOS application that is capable of connecting to a Mac remotely, and displaying the Mac's screen contents in real-time.
We have finally been able to receive and setup
our Mimio Capture and Mimio Teach system next to our workstation (see photo); the Mimio is being used as a tool to aid in the demonstration of a proof of concept for Access Lecture. Essentially, the Mimio system wirelessly transmits what is drawn on a whiteboard to a PC/Mac program. Our application contrasts with the Mimio in several important ways (hardware usage, portability, and accessibility focus to name a few), but the Mimio can still provide us with the ability to mimic the ideal/eventual functionality of Access Lecture.
Our task was to take the capture obtained by the Mimio, and make it viewable from within our application on the iPad. There are many possible ways to approach this problem; the approach we chose involves establishing a w
ireless, remote connection to a Mac which is running the Mimio software. We were able to utilize the open source iOS framework "Telekinesis" to easily obtain core remote-connection functionality. We built on-top of Telekinesis, and utilized it to stream the Mimio capture display to the iPad with little latency (about a 1 second delay). An example screenshot of the app displaying the Mimio capture from the whiteboard image above can be seen here.
Our proof of concept has the following requirements:
Well, that is all for this week. We're very excited with the significant leaps in progress that Access Lecture has seen since full-time development began just two weeks ago, and we plan to continue this trend in the weeks to come.
- Alex
Just as our second week of 9-5 development comes to an end, our "proof of concept" implementation does as well!
We have worked towards one primary goal this week: Create an iOS application that is capable of connecting to a Mac remotely, and displaying the Mac's screen contents in real-time.
We have finally been able to receive and setup
our Mimio Capture and Mimio Teach system next to our workstation (see photo); the Mimio is being used as a tool to aid in the demonstration of a proof of concept for Access Lecture. Essentially, the Mimio system wirelessly transmits what is drawn on a whiteboard to a PC/Mac program. Our application contrasts with the Mimio in several important ways (hardware usage, portability, and accessibility focus to name a few), but the Mimio can still provide us with the ability to mimic the ideal/eventual functionality of Access Lecture.Our task was to take the capture obtained by the Mimio, and make it viewable from within our application on the iPad. There are many possible ways to approach this problem; the approach we chose involves establishing a w
ireless, remote connection to a Mac which is running the Mimio software. We were able to utilize the open source iOS framework "Telekinesis" to easily obtain core remote-connection functionality. We built on-top of Telekinesis, and utilized it to stream the Mimio capture display to the iPad with little latency (about a 1 second delay). An example screenshot of the app displaying the Mimio capture from the whiteboard image above can be seen here.Our proof of concept has the following requirements:
- Access to a wireless network
- A Mac with the Telekinesis software installed, setup, and activated
Well, that is all for this week. We're very excited with the significant leaps in progress that Access Lecture has seen since full-time development began just two weeks ago, and we plan to continue this trend in the weeks to come.
- Alex
Tuesday, June 14, 2011
Update after the first week of fulltime development
Hey everyone!
So last week we posted to let you guys know about the tasks that we wrapped up and our plans for starting to develop the settings aspect of the application. We're getting pretty close to finishing our initial settings page so I thought I'd summarize the process we went through and what we ended up making.
To begin with, we decided we wanted a settings page that looked like the settings application that Apple uses. We read online after researching a bit that you could use a UISplitViewController to achieve the same look. "Great!" we thought and we eagerly began working on some UISplitViewController tutorials.
After messing around with the data structure for a while we started to notice something odd...it was incredibly difficult to make the SplitViewController exist on anything but the root view. Assuming we had simply hit a bump in the road, we consulted the SplitViewController documentation and lo and behold! Apple comes outright and says that Split View Controllers shouldn't be used outside of a root view.
Well that was bad news for us. Here we had found this magical class that could do everything we wanted, but the restrictions on it would keep us from being able to use it with our navigation-based application. We desperately searched through the depths of stack overflow and the split view controller references but alas, it simply could not be done. Unless you wanted to do something hacky and try to cheat the system, by attaching the split view controller to the rootview and then whenever the application loads quickly push another view on top to hide the split view. Well, that could have worked but the lack of elegance and the risk that it might get our application rejected from the app store made it seem like a pretty poor option.
And so we looked for alternatives and we found something called the InAppSettingsKit which has a bunch of wonderful open source code that allows developers to create a settings page very easily via editing a plist. Even more encouraging, there are plenty of apps that use it and are already in the app store.
We looked at a sample project where the InAppSettingsKit was used and then imported the InAppSettingsKit into our project and started working on the plist. Eventually we ended up with a lovely settings page that looks like this:
The great thing about InAppSettingsKit is it allows you to add setting options that bring the user to a custom view for changing the setting. We ended up doing this for the color changing settings, seen below
Another feature we wanted to mention was the toolbar transparency setting we added. During our usability tests a couple of the subjects pointed out that it'd be nice if you could turn toolbars transparent and then show more of the lecture behind them. This was a great idea and I worked on implementing it and now when you change the transparency setting (using a slider that alters the alpha value of the toolbar) you end up with something like this
As you can see, the lecture image now shows up behind the toolbars. Turning the toolbars transparent was very simple, but we also had to make sure that the scrollview displaying the lecture extended and retracted depending on what the transparency was set at. This also meant that when you go to the notes view to write on part of the lecture, it will need to show more or less of the image depending on whether or not toolbars are transparent. Lastly, I changed the minimum alpha value on the slider to be .3 because if you make a UI element too transparent, you will actually lose the ability to interact with it even if you click the space it was shown at.
So...we managed to get a lot done last week in regards to the settings, and our application actually saves the settings and will restore them after you close and reopen the application.
The professor we're working with also ordered us the Mimio to work with, and it arrived last week. We haven't had time to use it very much because we were wrapping up the settings, but this week we're going to start looking into the actual transmission of data from a computer to the iPad application. I don't think that any of us have worked on a program that involved that kind of logic before, so it's going to be an interesting experience for us all.
Lindsey
So last week we posted to let you guys know about the tasks that we wrapped up and our plans for starting to develop the settings aspect of the application. We're getting pretty close to finishing our initial settings page so I thought I'd summarize the process we went through and what we ended up making.
To begin with, we decided we wanted a settings page that looked like the settings application that Apple uses. We read online after researching a bit that you could use a UISplitViewController to achieve the same look. "Great!" we thought and we eagerly began working on some UISplitViewController tutorials.
After messing around with the data structure for a while we started to notice something odd...it was incredibly difficult to make the SplitViewController exist on anything but the root view. Assuming we had simply hit a bump in the road, we consulted the SplitViewController documentation and lo and behold! Apple comes outright and says that Split View Controllers shouldn't be used outside of a root view.
Well that was bad news for us. Here we had found this magical class that could do everything we wanted, but the restrictions on it would keep us from being able to use it with our navigation-based application. We desperately searched through the depths of stack overflow and the split view controller references but alas, it simply could not be done. Unless you wanted to do something hacky and try to cheat the system, by attaching the split view controller to the rootview and then whenever the application loads quickly push another view on top to hide the split view. Well, that could have worked but the lack of elegance and the risk that it might get our application rejected from the app store made it seem like a pretty poor option.
And so we looked for alternatives and we found something called the InAppSettingsKit which has a bunch of wonderful open source code that allows developers to create a settings page very easily via editing a plist. Even more encouraging, there are plenty of apps that use it and are already in the app store.
We looked at a sample project where the InAppSettingsKit was used and then imported the InAppSettingsKit into our project and started working on the plist. Eventually we ended up with a lovely settings page that looks like this:
The great thing about InAppSettingsKit is it allows you to add setting options that bring the user to a custom view for changing the setting. We ended up doing this for the color changing settings, seen below
Another feature we wanted to mention was the toolbar transparency setting we added. During our usability tests a couple of the subjects pointed out that it'd be nice if you could turn toolbars transparent and then show more of the lecture behind them. This was a great idea and I worked on implementing it and now when you change the transparency setting (using a slider that alters the alpha value of the toolbar) you end up with something like this
So...we managed to get a lot done last week in regards to the settings, and our application actually saves the settings and will restore them after you close and reopen the application.
The professor we're working with also ordered us the Mimio to work with, and it arrived last week. We haven't had time to use it very much because we were wrapping up the settings, but this week we're going to start looking into the actual transmission of data from a computer to the iPad application. I don't think that any of us have worked on a program that involved that kind of logic before, so it's going to be an interesting experience for us all.
Lindsey
Tuesday, June 7, 2011
Summer development starts
Hey guys,
Alex, Abhishek, and I are continuing our work on Access Lecture over the summer. We just working yesterday and we've already gotten a couple things done.
There's a lot more that we'll be working on this summer...this is just what we've accomplished during our first two days. We're going to be working every day during the week so there will be a lot more to come :)
Lindsey
Alex, Abhishek, and I are continuing our work on Access Lecture over the summer. We just working yesterday and we've already gotten a couple things done.
- Abhishek solved the zooming issues we were having and is now working on refactoring our zooming code by putting it in some other more appropriate classes
- I solved a couple of bugs with the note taking system that we didn't realize we had. Now our re-envisioning of the note system is working pretty well. We have two versions of it right now and for the version I was working on, the user can choose to take a "snapshot" of the current portion of the notes they're viewing and then write notes directly on that snapshot. A lot of the users during our usability testing wanted some way to annotate the notes or write directly on them and we believe this new system will be more in line with what the users were expecting.
- Alex was working on another version which was more similar to the old style of note taking we had but instead of typing notes, users could write them in a box that would appear below the lecture that's being viewed. While this provides less area to write with, and doesn't allow users to write onto the lectures, it allows them to take notes & view the lecture as it's happening in real time.
- Alex started working on adding a new page to the system where the user will be able to adjust settings for the system...
- And I started working on implementing some of the settings that users will be able to change, i.e. changing the color of tool bars, changing the transparency of tool bars, etc.
There's a lot more that we'll be working on this summer...this is just what we've accomplished during our first two days. We're going to be working every day during the week so there will be a lot more to come :)
Lindsey
Subscribe to:
Posts (Atom)