Talk:Website User Interface
From Open Siddur Project Development Wiki
Specific comments/questions:
I use the terms "core" and "contrib" a bit differently from the way you do, and we need a term clarification. For me, "core" includes all PD-derived texts and original materials that have gone through QC (quality control). "Contrib" includes all material that may someday migrate to core, but hasn't yet gone through QC. I also define a third category of content ("universe"?) for material that's not initially intended for core, for one reason or another -- the third category is the hardest to define guidelines for. The main difference between "core" and "contrib" is that "core" is actively maintained and has gone through the quality control process and "contrib" hasn't.
> 1.a.iv. encoded by section according to TEI JLP extension standard
Pretty much all data (except perhaps for data encoded in purpose-specific microformats) is in JLPTEI. This includes the recipes. A "recipe" is: (1) a set of conditional value-assignment statements (2) pointers into the text, indicating starting points (3) possibly, a local changeset against the original text [note: unless we do this carefully, it could break a recipe over time, so, I'm not sure how to do it].
> 1.a.vi. User edits of core content do not modify core
This is related to the as-yet undefined quality control procedures.
> 1.a.ix. Content licensed zlib, CC0 or CC-BY
We need to determine if CC-BY is allowed in PD-derived core. In my thoughts, "core" can include CC-BY-SA, just not for PD-derived texts.
> 1.b.vi.. Group collaboration space “owned” by user/adminstrators
What does "owned" mean, in context?
> 1. c.Partner contributed content > i.Content linked offsite > ii.Requires partner negotiations for redistributing content under CC0, CC-BY or CC-BY-SA
This entire section confuses me. The whole point of free content licensing is that *no* negotiations are required for sharing/redistribution. The distributor just has to read the license and follow its terms.
> 1.d. Offline and offsite content > i.Offline or online products or projects built on top of (or using) the Open Siddur must acknowledge use of the Open Siddur, its developers and community of participants
Not if they only use CC0 or zlib content. CC0 is like a public domain declaration. It has no content attribution requirements whatsoever. JLPPL (JLP Permissive License=our version of zlib license) has a content attribution requirement in source distributed forms only, and requests, but does not require, acknowledgment. It does, however, require that the distributor not claim the work as his own.
> ii.Printed content to carry license specific to Open Siddur content used
Depends on which part of the work they use. Again, if only CC0/zlib, a proprietary license can be attached to the binary by a distributor. Our software would probably tend toward making the total work available under the most-permissive possible license, while maintaining the requirements of all licenses (eg, proper acknowledgment clauses). *It is therefore a software requirement that it understand how to handle the licensing requirements of all supported copyright licenses.*
> iii.software projects building on JLP/OS code must be open source
Not really. The schema docs are GPL 2+ (derived from GPL 2+ material), so that's true for those [but not for use of the schema]. All the software I've committed is LGPL v3+. That means that the library itself remains FOSS, but it can be used in a proprietary product. We will, of course, be obligated in any licenses of software we reuse.
> iv.generated content may be commercial or non-commercial but remain open for culture hacking.
What is "generated content" here? To the best of my understanding, computers can't write creative works, so, generated content derives the copyright terms of its original source. > 2. b. User/Group Privacy
Setting up this infrastructure seems like a lot of work. Also, I question whether we should store data with any expectation of privacy at all. It may open up a number of cans of worms.
> 2. b.iv. Friends and groups can opt to share collaborated content and choose licenses with whole only with consensus decision using polls (majority polled? 2/3? 3/5?)
This is far less important than you might think at first thought. As long as all content is license-compatible, it's fine, and no consensus is required.
> 3.a.iii. User settings for user choice of default license to use for edited content and sharing privileges to friends and whole. (default is private, see above. License is default cc-by-sa).
Similar comments to above re: default licenses/privacy.
> 3.a.vii. Text in one recipe that is variant in other recipes is shown in RED. Clicking on RED text brings up a clickable layer to see variants in all the other nusachim.
This violates the W3C web accessibility guidelines (WCAG, http://www.w3.org/WAI/guid-tech.html), something which might be worth checking out while writing UI software. (In general, color should not be used as the only distinguishing factor between different elements; this is semi-violated in the POC haggadah, but it was never intended to be permanent. If color is used, red is a bad color to use, because of how common red-green colorblindness is.)
> 3. a. xiii. User can also apply upload, but not share their own (not necessarily open source) fonts for application to specific text, or for automatic application to text already tagged as certain sections or from certain periods/sources of authorship.
I'm not sure if this is legal under most proprietary fonts' EULAs. Do we want to encourage use of proprietary software, anyway? From a technical perspective, what I think you really want is an association of a style to certain semantic values.
> 3. a. xiii. Renedered siddur in pdf, content exportable as XML.
Eventually, I'd like to minimally have the following exports (transforms): JLPTEI (essentially, a database dump, no changes from original, possibly as a tarball/zip), PDF, PostScript (essentially comes free with PDF) XHTML+CSS
> 3. a. xiv. Updates available as RSS
Not sure what this means?
> 3. c. i. Users, User groups, and the whole (non-user visitors) can access siddurim in various formats (e.g., pdf, xml) and shared universally
We're going to have to balance the space constraints of keeping minute-difference binaries against the computational time of recompiling the recipes.
