About: Mobile Touchpad

Description
Metadata
Settings
- owl:sameAs
- Inference Rule:

About: Mobile Touchpad Sponge Permalink

An Entity of Type : owl:Thing, within Data Space : 134.155.108.49:8890 associated with source dataset(s)

The Mobile_Touchpad is a two screen application that is written for use on a smart phone. * The first screen collects the names of the students and staff from a web page. * On the first screen, the user can click the preference button to check the name of the device. If the device is wrong, then the proper name can be inserted. The device name might be as simple as "Erik's iPhone." That device name is written into the attribution part of the check in statement. * On the second screen, the top field is where users type in the name of the student to "check in." As the typing begins, options appear on the screen below. Once a SINGLE NAME remains, then the bigger check in button can be clicked and then the magic happens. The name is uploaded to the web . * Audio feedback happ

Attributes	Values
rdfs:label	Mobile Touchpad
rdfs:comment	The Mobile_Touchpad is a two screen application that is written for use on a smart phone. * The first screen collects the names of the students and staff from a web page. * On the first screen, the user can click the preference button to check the name of the device. If the device is wrong, then the proper name can be inserted. The device name might be as simple as "Erik's iPhone." That device name is written into the attribution part of the check in statement. * On the second screen, the top field is where users type in the name of the student to "check in." As the typing begins, options appear on the screen below. Once a SINGLE NAME remains, then the bigger check in button can be clicked and then the magic happens. The name is uploaded to the web . * Audio feedback happ
dcterms:subject	Technology dbkwik:resource/ZUi_f8IuoCPmOLE_EkxpOA==
abstract	The Mobile_Touchpad is a two screen application that is written for use on a smart phone. * The first screen collects the names of the students and staff from a web page. * On the first screen, the user can click the preference button to check the name of the device. If the device is wrong, then the proper name can be inserted. The device name might be as simple as "Erik's iPhone." That device name is written into the attribution part of the check in statement. * On the second screen, the top field is where users type in the name of the student to "check in." As the typing begins, options appear on the screen below. Once a SINGLE NAME remains, then the bigger check in button can be clicked and then the magic happens. The name is uploaded to the web . * Audio feedback happens as the name is uploaded. To Develop * Photos of the students could be shown before and after a student checks in with the application. * Photos would need to be uploaded to a certain directory and be built with the student's first and last name dot jpg. * At present, there is no fixing a false check in. If a student or operator miss-leads, then the entry can not be terminated. For now, be accurate. * Perhaps an undo function would have a button would save the past 10 check ins. Then a table would be shown to have a check-box and then re-write on the server, removing and then replacing those messages. * Upload a new participant is not yet working. So, if a person joins the class who has NEVER been a part of the team roster, then that person can not be checked into the activity. * Could put a person right into the main file on the server. However, that would be less than ideal as there would be no database record for that individual. * Could just write a message to the server, "Check in of JOE JOKES an UNLISTED individual with a phone number of xxx-xxx-xxxx at time location. Try out swimmer, perhaps. Do get the phone number. * Could add a one-time visitor with the PREFERENCES button on the first screen. * Upon the visitor check in, the main database application would have to be able to deal with that person and create a message after it fetches the info. That script is not done yet either. * Perhaps a photo of the visitor is also taken at the check-in. * Perhaps a photo flag is sent if the person is checking in but without a photo. Back key support for Android needed. All we need to do is add a backKey message to our stack script that checks what card we are on and takes the appropriate action. on backKey if the number of this card is 1 then pass backKey else go to the previous card end if end backKey

OpenLink Virtuoso version 07.20.3217, on Linux (x86_64-pc-linux-gnu), Standard Edition
Data on this page belongs to its respective rights holders.
Virtuoso Faceted Browser Copyright © 2009-2012 OpenLink Software