Create business requirements document

ericchu94 commented 9 years ago

Store in /documentation

Determine what is the problem that is to be solved, and the solution to the problem. This documentation should be of a very high level.

Examples: Things to include (BRD stuff):

Users should be able to chat with other users
Users should receive chat messages in real-time
Message should be displayed chronologically
Users should need to authenticate

Things not to include (FSD stuff):

Messages are stored in a database table with columns ...
The login page looks like...
The user creates a chat by clicking another user...

FlipEnergy commented 9 years ago

@ericchu94 Definitely needs review. I'd like to make sure our visions of the project are the same. I want the modules to progress in a good fashion, e.g. we don't have to go back and redo a lot of work to implement new changes.

ericchu94 commented 9 years ago

@FlipEnergy

There is a requirement that previous messages must be view-able.
The whole concept of chat rooms is confusing to me.
- The can be multiple chat rooms with the same users present in them?
- There is no way to name chat rooms?
  - If yes, then are the names unique?
- Are we listing chat rooms?
- There needs to be a way to administrate chat rooms.

The chat room thing feels weird. I can see it working, but originally I thought to have chat rooms strongly coupled with users, but this seems to work better.

FlipEnergy commented 9 years ago

@ericchu94

Well, chat rooms are how I'm understanding what we want to achieve. Especially as it is in the beginning in Module 1. Afterwards, I'm not so sure either. But I was thinking that having multiple chat rooms can have the same users, and the names for the chat rooms would default as a list of usernames of people in it. Later on, we can have the option to change the chat room name. I can see why it may be confusing but these "chat rooms" are eventually just going to be instances between two or more people, like facebook messenger. Not really like a lounge-type where people just join and leave to chat with randoms.

As for administrating chat rooms, I'm not too sure. I'm just not entirely sure how your approach would be.

ericchu94 commented 9 years ago

Your description of chat rooms from the comment is inconsistent to the BRD. You cannot simply say that you want these chat rooms to be similar to facebook messenger. Define the attributes associated to facebook messenger in the BRD.

Add/modify/remove friends from contact list

How can I modify a friend from the contact list?

join the room the contact is in from contact list

The requirement does not make sense. A contact does not have a one-to-one mapping to a room

If a chatroom consisting of a group of users already exists, users can rejoin chatroom after signing off

This requirement does not make sense. This works to enforce that only chat rooms are unique on the participants field, whilst it is defined that chat rooms are not. It raises the question: which chatroom is the user rejoining into?

FlipEnergy commented 9 years ago

That's a good point. I didn't think of that. I want to know how you would describe what you had in mind. If not a chat room type setup, what instead? Should we restrict contacts to only one room or whatever?

ericchu94 commented 9 years ago

I don't know. As long as you can figure out something that works and makes sense.

The first question I would like to solve is whether there can be multiple chats between the same 2 people.

Pros of multiple chats:

Topic based discussion
More organized
Works better when integrating group chats

Cons of multiple chats:

Not as easy to use
Possible clutter (too many chats)

The use case I'm having trouble with is the following:

A chat between 2 people is started
A third person is added
- Does the 3rd person see the messages that existed prior to joining?
- What happens to the original 2 participant chat?

FlipEnergy commented 9 years ago

Well I don't think multiple chats between the same 2 people should be allowed. It's just unnecessary.

I'm going to edit the the document first. Then let you review it further.

FlipEnergy commented 9 years ago

@ericchu94 Please review again.

ericchu94 commented 9 years ago

There needs to be a way for users to leave group chats since a user should be able to opt-out of chatting.

ericchu94 commented 9 years ago

Added comments on commit

FlipEnergy commented 9 years ago

@ericchu94

Removed arbitrary limit on old messages
There are two ways of making a group chat, In module 4, users can create new instances, these can be groups or one-on-one. I also made changes in Module 5 for adding contacts into existing chats.
Added option for users to leave group chat in Module 4

ericchu94 commented 9 years ago

@FlipEnergy You mentioned:

Well I don't think multiple chats between the same 2 people should be allowed. It's just unnecessary.

But it is not in the brd?

Added comments to commit

FlipEnergy commented 9 years ago

@ericchu94

Made some changes but as for this comment in Module 5:

Why should this behavior be different than the one-on-one behavior mentioned below?

This way a group chat can be expanded to include more people but if two people are chatting, their chat history is not sacrificed.

I played around with FB messenger and it seems this is the way they do it. There could be a better way. Any ideas? Also any more feature suggestions to add?

ericchu94 commented 9 years ago

Okay I see the benefits of having 2 different behaviors. It seems reasonable

FlipEnergy commented 9 years ago

@ericchu94 One more total review please.

ericchu94 commented 9 years ago

@FlipEnergy There is a requirement that each message has a associated timestamp. More comments on commit

FlipEnergy commented 9 years ago

@ericchu94 Thanks for the feedback. Please review again.

FlipEnergy commented 9 years ago

@ericchu94 Made a new commit based on your comments. Please check again and tell me what you think about deleting a chat instance if all participants left. Is there any point to keep it around? Should we add a rejoin option for a future module?

ericchu94 commented 9 years ago

@FlipEnergy I think we are almost there...

FlipEnergy commented 9 years ago

@ericchu94 Review again please.

ericchu94 commented 9 years ago

Added comments

FlipEnergy commented 9 years ago

@ericchu94 I thought keeping a one person group chat could be okay as well in case they want to read the chat history. But from last review, I thought you said you you want to disallow single person chats. Did you change your mind?

ericchu94 commented 9 years ago

no

FlipEnergy commented 9 years ago

@ericchu94 Then I don't understand what you mean by the most recent commit comment. Please elaborate? Or are you actually asking?

ericchu94 commented 9 years ago

I don't think we should allow a user to chat in a group chat
A user must be able to see the history of a group chat if the user did not leave

FlipEnergy commented 9 years ago

@ericchu94 Made another update. Should be a bit more clear now. Review once more please.

ericchu94 commented 9 years ago

You still have not fixed the previously mentioned issue

A group chat should not be removed if there is only 1 user

FlipEnergy commented 9 years ago

There seems to be a contradiction. I'm not sure what you're trying to say. You want to disallow one person chats, but you want a person to be able to still read the chat history if they are the only one left in a group chat.

Similar to below, disallow single user group chats

Why shouldn't the remaining person be able to read the chat history?

ericchu94 commented 9 years ago

Sorry for my wording The following is more clear:

A user should not be able to chat in a group chat if it is the sole user

A user must be able to see the history of a group chat if the user did not leave

FlipEnergy commented 9 years ago

So you're saying, if a user is the sole participant in a group chat, he/she cannot chat but should still be able to view the chat history? So you want to disable the chatting but not remove the room?

ericchu94 commented 9 years ago

That is a possible solution

FlipEnergy commented 9 years ago

Do you think there is a better way?

ericchu94 commented 9 years ago

I don't have any other ideas at the moment

FlipEnergy commented 9 years ago

@ericchu94 Once more please.

ericchu94 commented 9 years ago

Looks good to me.

@allenh:

Please review as you are making the FSD
Note that every single bullet in the FSD should correspond to at least 1 bullet in the BRD

ericchu94 commented 9 years ago

@allenh It has been 4 days. Do you have an update?

allenh commented 9 years ago

@ericchu94 No, not yet. I am still thinking what in the BRD needs to be changed to fit better with FSD

ericchu94 commented 9 years ago

@allenh we are not following a Waterfall model; there can and will be reiterations.

If it is taking so long, it'll be a good idea to just finish this review and get started on your own ticket. If problems arrive, simply open up another issue to address it.

ericchu94 commented 9 years ago

@allenh is there a status update on this issue?

allenh commented 9 years ago

@FlipEnergy @ericchu94 Sorry for the delay of the review, I was quite busy for the past few days.

For the BRD I have some suggestions and question and they are as follows:

Suggestions:

Module 3

User able to change display name

Module 4

The user who creates the chat is able to remove participant in the chat instance
The participant who left the chat instance is able to review the all the chat history until to the point that s/he left the instance

Question:

How do you vision the history of the chat to be viewed? Is it just going to be stored in the chat instance?

FlipEnergy commented 9 years ago

Changing display name is a pretty good idea, but maybe we should limit the number of times they can do that so they don't just keep doing it?
removing will be added to module 5
Not sure about still being able to view chat history even going out. If we do, maybe we can make a copy of the instance at that point and disable chatting or something.

@ericchu94 Thoughts?

ericchu94 commented 9 years ago

Changing display name (user name?) is nice, abuse of the system is not. Setup a control system I guess? (Timeouts, absolute limit, limit per duration, etc). Are the display names unique?

Removing is nice as well (that was what I was talking about when I mentioned chat room administration).

I think a leaver should be able to read chat history. How it is implemented is not relevant here; only if it is feasible.

FlipEnergy commented 9 years ago

@allenh Added your suggested features. Check again please.

allenh commented 9 years ago

@FlipEnergy It looks good to me.

ericchu94 commented 9 years ago

What happens when a user can't change their username?

Due to unique constraint
Due to changing too many times

What happens when a user has left the room (kicked/voluntary)?

FlipEnergy commented 9 years ago

I suppose we should have (popup?) messages for those to tell the user why they can't change their username or if they're kicked or left.

FlipEnergy commented 9 years ago

This okay? The message could actually just be added in the chat as like a system message.

ericchu94 commented 9 years ago

Commented on commit

FlipEnergy commented 9 years ago

@ericchu94 Made the quick fixes.

ericchu94 commented 9 years ago

I really do not believe a popup is a good user experience. Besides, the mechanism of delivery should not be specified here, it is the requirement of a delivery that should be. Hence business requirements document and functional specifications document.

ericchu94 / chat