This page is to document the set of design principles and requirements regarding ways of accessing OpenGuides data in a global context - ie without needing to know which guide it should go in. This is more details of what is discussed in #64.
What are the goals?
- search for a place globally - automatically be redirected to the appropriate guide
- Editing/browsing interface
- Global API interfaces
How should they be implemented?
- portal.openguides.org running a completely separately codebase to integrate requests and searches and distribute them to guides using an open API
- cache results?
- Dedicated OpenGuides server possibility - Dom has hardware to be set up
- Integration into http://openguides.org/ (redesign/replace this website)
What is required of the OpenGuides codebase?
- Standard styles as a base
- Expose what area they think they cover in a machine readable format
What challenges need to be met?
- How do we cope with coverage where there is no existing guide?
- Single global guide that can have data siphoned off it if someone wants to create a more specific guide?
- Existing global special purpose guides? (eg engineer.openguides.org)
- Vaguely consistent, but adaptable branding/styling so that people don't get completely confused
- Defining scope of a guide?
- cotswolds and oxford OGs don't overlap, but touch. If you did a bbox for both, they would overlap though
