Features that affect the very bottom of the architecture. Like, are we making a web site or a Java P2P hive.
synchronization
- keeping data updated across entire communities
- what needs to be synchonized and when?
- define latencies for different types
- software and data (down and up)
| issue | code | content | interactions |
|---|---|---|---|
| generator | developer | author | learner |
| authority | central? | central and endpoint | endpoint |
user location transparency
- student does work at school, continues at home
- teacher runs class at school, grades at home
- researcher wants to analyze data of learner wherever
integrate other hardware
- handhelds
- phones
- bluetooth
- graphic calculators
- probeware
link to existing tech more tightly
- office software
- stats packages
real-time communication, data sharing between users
- Cross Team Note Critique. Give the system the ability to send a Note from one team to another team for review/rating. - Matt Fishbach
- instructor monitoring student progress, learner data.
- shared document editing - support multiple people changing a single document
- if user data privacy is important this becomes difficult with unsecure local storage
share collected data with other classes, projects
flow control
- manual (by a person)
- facilitator can stop all student interaction with the system and direct their attention
- facilitator brings sends all learners to particular state
- facilitator blocks all users from particular state until ...
- facilitator changes content/sequencing on the fly, based on student interactions
- automated (fancy sequencing, conditional on learner data, date, etc)
- step A creates condition that prevents learner from advancing to step B (or after)
peripheral content
- broadcasting exemplary work
preventing data from access (even in principle)
flipside: all data potentially accessible (assuming adequate privileges)
easy setup
- click and use
users
- types
- authentication
- userbase
learning without any network
learning with a fast LAN and slow WAN
student work in session safe regardless server failures
- Failsafe system for saving Notes. Automatic local autosave. Or "Save Draft" button. I recommend adding a solution to make sure students do not lose work in progress on Notes, which I saw happen several times last semester. Autosaves or Save Drafts could be saved silently to the local drive. - Matt Fishbach
Perspectives of Scott Cytacki
I couldn't get comments to work. Or at least I couldn't see them so I'll do it this way. Hope this doesn't pollute the page too much.
Can you add a rational of why each of these features is level one? Some are obvious for example learning without any network and easy setup. Others like flow control, preventing data from access, and share collected... after some thought I can see how an intermitent network and unsecure local storage make these difficult.
Comments (1)
Mar 12, 2004
Turadg Aleahmad says:
Level 1 means the bottom level, not the most essential features. That the flow c...Level 1 means the bottom level, not the most essential features.
That the flow control, preventing data from access, etc. are difficult in Level 1 is why we must consider them now before we make decisions in designing Level 1 that prevent those features. And we need to determine the important of them in decideding whether to make compromises in our design to accomodate them.