Skip to content
This repository has been archived by the owner on Jan 10, 2024. It is now read-only.

Study Cards #457

Closed
10 of 16 tasks
sebmarste opened this issue May 19, 2017 · 13 comments
Closed
10 of 16 tasks

Study Cards #457

sebmarste opened this issue May 19, 2017 · 13 comments

Comments

@sebmarste
Copy link
Contributor

sebmarste commented May 19, 2017

Documentation see wiki/Study-Cards

Outline

For every lecture attending students can create study cards containing a question text and an answer text representing a front and a back side of a classical paper study card. Optionally a card can contain an image on the front and or back side. These Cards sorted by the lectures and by custom tags. Using this structure all students can see, the cards, search through them and edit them as well.
After the creation the students can use the cards to learn the content in a quiz style process. First they see the question and can think about it. After they pressed so see the answer they can give feedback whether they knew the answer or not. Furthermore they can give feedback about the content of the card or add a comment.

Milestones

Milestone A

Develop a model and a first simple backend API implementation.

Milestone B

Use the API provided by the backend to create a first simple frontend containing the creation process as well as the quiz process.

Milestone C (optional)

Implement tag structure, editing of cards, feedback to the card content as well as commenting features.

Next Steps

  • add card title to model
  • rename user to member in model
  • add rating to comment in model
  • add/edit card mockup
  • quiz mockups
  • aggregated rating
  • mark card as duplicate of another
  • filter cards by creator
  • add tags in card add/edit/view screen
  • model active days
  • Created at in edit and filter
  • Add possiblity to show card or remove card in quiz
  • Add possibility to add card or remove card in card view
  • Settings wheel in overview becomes build icon (wrench symbol)
  • Add creator to card item
  • endpoint specification
@sebmarste
Copy link
Contributor Author

@kordianbruck please review this model
i will improve and restrict it in dialog with you
feel free to ask questions

my next steps would be

  • mode detailed db model (types, keys, ...)
  • endpoint specification
  • android ui mocks

@kordianbruck
Copy link
Member

Here are a few ideas:

  • please just use card and prefix all the tables with that
  • tables should be all lowercase
  • PKs should have the name of the table
  • Types: 'normal', 'single', 'multiple' - What is 'sort'?
  • user should be member
  • Tags are relevant to group cards into sections of the lecture right? You are missing a relationship table here as it should be m:n no? Please explain this further.
  • history is the progress or answers given right? Please rename this to better fit its purpose. History I associate how a card would have changed over time
  • I'm not certain about the bags thing. This is more about the learning strategy right? Usually the card progresses through several stages on how often it was answered correctly. So from stage 1 to 2, you would need to answer it correctly 3 times, then from 2 - 3 you would need to answer it twice and then from 3-4 you only need to answer it once. There are a lot of strategies out there and I would not focus on how to implement this at this moment.

Please change those points and we will go more in depth in the next iteration.

@sebmarste
Copy link
Contributor Author

sebmarste commented Jun 22, 2017

@kordianbruck here some answers:

  • please just use card and prefix all the tables with that
    done
  • tables should be all lowercase
    done
  • PKs should have the name of the table
    done
  • Types: 'normal', 'single', 'multiple' - What is 'sort'?
    just an idea: several options/steps/... that must have a specific sort order, but I think this should not be part of the investigation right now as this can be extended simply in the future
  • user should be member
    member of the model or rename?
  • Tags are relevant to group cards into sections of the lecture right? You are missing a relationship table here as it should be m:n no? Please explain this further.
    done, just like labels in github - so that the users have a tool to manage cards independent from lectures (chapter | general topic | difficulty | ...)
  • history is the progress or answers given right? Please rename this to better fit its purpose. History I associate how a card would have changed over time
    done - renamed to users_card_answer_history
  • I'm not certain about the bags thing. This is more about the learning strategy right? Usually the card progresses through several stages on how often it was answered correctly. So from stage 1 to 2, you would need to answer it correctly 3 times, then from 2 - 3 you would need to answer it twice and then from 3-4 you only need to answer it once. There are a lot of strategies out there and I would not focus on how to implement this at this moment.
    have a look at the german flashcard system wikipedia page, usually the bag defines when the user has to answer the card again (eg: bag 0: same day, bag 1: after 1 day, bag 2: after 3 days, ...) this would be quite simple to implement and even to configure by the user, but im not fixed at this idea, if you have a better idea tell me ;)

@kordianbruck
Copy link
Member

kordianbruck commented Jun 28, 2017

member of the model or rename?

we are using chat_members here, so rename please

have a look at the german flashcard system wikipedia page, usually the bag defines when the user has to answer the card again (eg: bag 0: same day, bag 1: after 1 day, bag 2: after 3 days, ...) this would be quite simple to implement and even to configure by the user, but im not fixed at this idea, if you have a better idea tell me ;)

I doubt anyone is gonna do this on a daily basis. Please come up with a system that is practical to the span of a semester ;)

@sebmarste
Copy link
Contributor Author

sebmarste commented Jun 29, 2017

@kordianbruck I've moved model and mockups to the wiki, please review it

@kordianbruck
Copy link
Member

Model looks good now. I think we can work with that. Do you already have it done in SQL as well?

Mockups

Absolutely great work on those! 🥇 💯

Overview

  • I would not recommend a settings wheel on the sub page in the toolbar
  • Search is great
  • The graph might just take away too much space from the layout. Not feasible for a first implementation

Search

  • Don't think the additional filter is really necessary
  • Please utilize the already existing search layout

Delete / Add

  • Why are those too separate screens?
  • I would rather vouch for a manage my cards section for each lecture

Filters

  • I like it. Not sure we need the students to be able to filter by box.
  • Also this needs to be simpler. I think people will get a bit lost.

Edit Card

  • I think that your layout is really tightly spaced. Default Android forms only are vertical

Overall

I think the box system should be less transparent to the user. We do not want to slam them with too much information. If he wants to see his currents stats / status of the boxes this should be possible, but on a different screen.
I would encourage to think a bit more about navigation between screens. The Overview should contain a list of all my lectures that I participate in. Then only in the next step I'll see the cards in that lecture.
I think a toggle button, if I want only my cards or all cards when quizzing would be a nice to have.

We need to start limiting the scope of this thing if you really want to finish in the next weeks. Whats your time plan / schedule / availability? Do you want to continue to work on this afterwards?

@sebmarste
Copy link
Contributor Author

sebmarste commented Jul 6, 2017

@kordianbruck

Model | Database

sql script is pushed on the study-cards branch in the backend repo

Android

When the user enters the study card section he will

  • add new Cards (often)
  • start a quiz (often)
  • start a quiz with a filtered card set (sometimes)
  • add Cards to his set (seldom)
  • remove Cards from his set (seldom)
  • change box settings (only once)

So the first screen should have a good overview about his current state ("do i have hards in the queue?") and prominent placed buttons for adding a new card and starting a (filtered) quiz.

The idea is to have only three screens:

Overview

Here the user can:

  • get an overview about his current state
  • manage his cards (adding and deleting using the filters, search)
  • start a quiz
  • start a quiz with a filtered card set (the quiz is executed on the actual filtered cards)
  • go to the add new card screen
  • go to the cards settings screen (i will use a wrench icon instead of the settings wheel)

the add new card button and the graph (whatever it may shows, not implemented in this scope) will scroll together with the list of cards and therefore do not use space which is needed to manage the cards
The Filtering is active in all modi (inkl search) but are preset to contextual fitting settings

Card

Here the user can create/view/edit/comment a card
The layout will be with enough space (material design)

Quiz

Here the user can answer his quiz

Organizational

i will go on in the following steps:
implement the simplest user story

  • add a new card (only type normal)
  • add/remove card from box
  • get cards (with first simple query params)
  • simple quiz with these cards

i hope that i can manage this in the scope of the praktikum
As i think the other features are modeled quite well we could think about going on with this on the next android praktikum with a new team, i cant promise if/how much implementation stuff i can do on this in the nearer future after this semester, but we will see ;)

@kordianbruck
Copy link
Member

kordianbruck commented Jul 6, 2017

Again: a user should not be able to modify the boxes. Those should work automatically.

add Cards to his set (seldom)
remove Cards from his set (seldom)

We need to simplify this: only allow users to subscribe to a lecture. If hes subscribed he can choose to participate collaboratively or not.

Edit: Your scope seems reasonable.

@sebmarste
Copy link
Contributor Author

sebmarste commented Jul 6, 2017

@kordianbruck do i understand it correctly, that in your approach subscribing to a lecture adds all cards in this lecture to the users set and unsubscribing removes all of them?

I would separate the boxes completely from the users set:
the user manages which cards of a lecture are in the users card set (and therefore used in quiz and automatically managed in the users boxes)

this would be a fundamental difference


Until now there are no lectures on the back end, should I simply match on the lecture name again or add a entity (where a lecture is added when needed)?

@thellmund
Copy link
Contributor

@kordianbruck, can this be closed, as the effort to implement study cards is canceled?

@thellmund
Copy link
Contributor

@kordianbruck Can this be closed?

@pfent
Copy link
Contributor

pfent commented Sep 28, 2018

@thellmund closed due to inactivity 😉

@pfent pfent closed this as completed Sep 28, 2018
@kordianbruck
Copy link
Member

kordianbruck commented Sep 28, 2018

Thanks for giving me like almost an hour to reply. 👍

Anyways: I want to push the Campus App from a pure information only app, to a more interactive app. I still think, this is a cool feature and has lots of it merit, but at the current time its too tricky to implement. Maybe its a feature for the next practical course team. Right now, you are right, its not feasible to implement due to a lack in manpower (till 😭 )

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants