Hi Michael and Joey, I think we should have "favorite" and "read later" separate. This is also what Google Reader and Feedly do (and, in fact, Thunderbird too). I find it useful to keep them separate because this opens up for four possible states, which are all quite nice to have:
- Not read, not favorite - basically every new article is in this state - Read, not favorite - all articles that I have read, but am done with - Read, favorite - those articles that I think were so good that I want to read them again, or show them to someone else. This makes it easy to find them later, but they are no longer "urgent". - Not read, favorite - the title of the article tells me that it is important, so I have it favorited (or equivalently starred in an e-mail client) to distinguish it from all those other articles I have read. This is an "urgent" state. Another reason I think it is useful is because the indication of favorite and unread could be different. Feedly and Google Reader has solved this with a star for favorites and bold font for unread. I find that way of giving indication both useful and nice. Svenn-Arne On Thu 25 Apr 2013 05:12:37 PM CEST, Joey Chan wrote: > Hi Michael, > > Good question :P > > My friend and I have discuss this question for several hours, then our > final explanation is : the "favourite"(forever) includes "read > later"(temporarily) . > > From the user's point of view, if the user mark a article "read later" > that means user wants to keep this article for a while, kind of > temporarily; if the user wants to keep this article forever, just mark > it "favourite", of course the user will "read it later". > > Thanks for asking this question :) > > > 2013/4/25 Michael Hall <[email protected] <mailto:[email protected]>> > > This would mean that an article can't be both favorite and "read > later", > is that desirable/acceptable? > > Michael Hall > [email protected] <mailto:[email protected]> > > On 04/25/2013 04:27 AM, Joey Chan wrote: > > sorry... wrong E-R diagram, here's the correct one: > > > > 内嵌图片 1 > > > > > > 2013/4/25 Joey Chan <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > > Hi Gentlemen, > > > > I consult one of my friends who is a database specialist, he > advise > > me to combine "favourite" and "readlater" into an attribute > called > > "status" of article entity, to make the database designs more > > simple, here's the new E-R diagram: > > 内嵌图片 1 > > > > > > According to this diagram, only three database tables are > needed. > > > > Any different opinions are welcome :) > > > > > > > > 2013/4/22 Joey Chan <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > > Hi Svenn-Arne, > > > > Agree with your advice that rename "Tag" to "category", we > > developers will easily understand what the functions > would like. > > > > For avoiding duplicate tag names, this is a good idea > but should > > not be included in this part(database), will talk about > later. > > > > :) > > > > > > 2013/4/22 Svenn-Arne Dragly <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > > > > I think it looks like a very good core design for > the database. > > > > We could rename "tag" to "category". It is likely > that the > > user will want to organize feeds in different > categories to > > merge them in one view. For instance "Business", "News", > > "Hobbies", "Sports", etc. > > > > "Tags" and "categories" from a database perspective is > > pretty much the same, so the proposal to rename "Tag" to > > "category" is merely to emphasize that it will be > used as a > > strong organizing tool. (Basically, I want to avoid > having > > the user create multiple tags like "hobbies", > "hobby", "my > > hobbies" for the same thing, and rather put them all > in one > > category, "Hobby"). > > > > > > Great work! > > > > > > On 04/22/2013 11:38 AM, Joey Chan wrote: > >> Seems that was my misunderstand :P > >> > >> So, any further suggestion or advices to the E-R > diagram? > >> > >> > >> 2013/4/22 <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > >> > >> I think we have misunderstanding. > >> > >> Look in databasemodule.js > >> > >> We have two tables, "userfeeds" and > "feedentries" (mb > >> not exact names, I can't check actual names). > >> > >> > >> 22.04.13 13:06 Joey Chan написал(а): > >> > >> Hi Roman, > >> > >> Not similar exactly, I separate the > article(item) from > >> feed because I want to store the feeds and > >> articles(items) in separate database tables. > This may > >> sounds a bit complicated but I think this is > necessary. > >> > >> :) > >> > >> > >> 2013/4/22 <[email protected] > <mailto:[email protected]> <mailto:[email protected] > <mailto:[email protected]>>> > >> > >> We already have similar model, without > favourites > >> and tags, am I right? =) > >> > >> > >> 22.04.13 6:49 Joey Chan написал(а): > >> > >> Hi Ladies and Gentlemen, > >> > >> I've done the E-R diagram of RSS Reader, > preview: > >> 内嵌图片 1 > >> > >> description: > >> > >> 1. feed is the primary entity, it may contains > >> many "tags" , "articles(items)" and > >> necessary attributes; > >> > >> 2. article(item) is the secondary entity, every > >> article(item) has its own attributes. > >> I separate article(item) from feed(which has a > >> complete xml include articles) because the > reader > >> doesn't need to read the whole xml content > if the > >> user just wants to read one article, also, the > >> design team will have more freedom to > design the > >> interaction with one article(item); > >> > >> 3. tag, means ... maybe call it "category" > >_< > >> > >> 4. favourite, favourite articles; > >> > >> * the attachment is a gia source file, pls use > >> Dia(sudo apt-get install dia) to open it > and feel > >> free to discuss :) > >> > >> > >> > >> > >> > >> > > > > > > > > > > > > > > -- > Mailing list: https://launchpad.net/~ubuntu-touch-coreapps > Post to : [email protected] > <mailto:[email protected]> > Unsubscribe : https://launchpad.net/~ubuntu-touch-coreapps > More help : https://help.launchpad.net/ListHelp > > > > -- Mailing list: https://launchpad.net/~ubuntu-touch-coreapps Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-touch-coreapps More help : https://help.launchpad.net/ListHelp
