Team 3 - rsanchez-wsu/jfiles GitHub Wiki

#Contributers
Zach Wells
zw3lls17 (Github)
zw3lls (slack)

Randy Musser randymusser (Github/slack)

Alex Despain
masters1222 (GitHub / slack)

Nick Weaver
nickwvr (GitHub)

Erik Matthews
matthews92 (GitHub)
erik (slack)

#GUI Design JFiles is a remote file system, meaning it should look and feel similar to most file systems people are used to. Considering it is a remote system, the GUI may also call for extra features such as logging in or a display for the user's connection. Team 3 has worked on primarily GUI design and functionality, so this page should contain most of what is needed to know about the GUI outside of the code. ##Design Functionality The following list contains functionalities that should be considered as the bare minimum of the GUI. Without these, it should not be considered complete. They do not describe how it should be done, but rather what be implemented.

  • Files can be created, deleted, and opened through the GUI.
  • Folders can be created, deleted, and files can be move into and out of folders.
  • The GUI displays files and folders based on the user's location in the directory.
  • The user can scroll through files and folders. Meaning the window does not have to be incredibly large if numerous files or folders are in the current location.
  • The GUI window can be resized.
  • Both files and folders can be cut, copied, and pasted to new locations in the file system.
  • The user should be able to rename files and change their file extensions.
  • The directory can be traversed through a given path. For example, in windows a path looks similar to:
    C:\Program Files\Common Files\Java.
  • The GUI should have some way to output text to the users for things such as error logging or connection status.
  • The GUI has a way to show connection status, connected or not connected, to the remote file system.

##Aesthetic Functionality The following list contains functionality that makes the GUI easier to use. It can still function without these, but they should significantly improve convenience factors for using the GUI.

  • Different file types have different icons displayed.
  • Similar to browsers and files systems, the GUI should have a way to go to back to where they came from in the directory. This functionality should be implemented to have the common forward functionality as well.
  • The GUI allows the user to search for specific files.
  • The GUI can be refreshed. This essentially means that changes made in the current location in the directory will be reflected if not already. This could also mean reordering the files so that they are displayed how they would be when changed from one spot to the directory to that current spot.
  • Users can undo or redo an action such as deleting or moving a file.
  • Files and folders can be sorted based off of characteristic traits. These could be sorted by alphabetical order, file type, etc.
  • Multiple windows of the GUI can be opened and are interactive with each other. Meaning you can drag and drop files from one window to the next.
  • Different ways to view folders and files such as in a list or as square icons in a grid.
  • Users can choose how big icons are displayed.
  • The amount of details displayed for files and folders can be changed.
  • The ability to interact the remote file system with a local one.

#Food for Thought The following items are what you may want to keep in mind about this project as a whole. These may not be immediate threats, but they are large design choices that should be taken care of delicately. The GUI ties into a lot of other parts of the project and some design concepts may not have been chosen or implemented yet. Most of these items will need to be agreed upon with everybody else.

##Authentication It is a Group File System: meaning users will be able to see the same files that others can. These questions help with things to keep in mind when users first access the GUI.

  • How should the user be recognized? Should they have a username and password, remembered by IP address, etc.?
  • If users need usernames and passwords how will they be stored in the database?
  • What if the same user logs in from a different IP or their IP changes?
  • How will users be given permissions based off of identifying them?
  • What different levels of users could there be and their corresponding permissions?

##Caching and Database For the GUI it is useful to keep some data around to implement certain functionalities, caching makes this quick and easy. Things that need to be kept long term should be put in the database instead. The following list includes things that may be important to cache or store in the database for later.

  • The previous location in file system. This helps with the forward and back buttons.
  • Deleted files. In case something is accidentally or maliciously deleted, it is good practice to have a temporary back up.
  • The last changed item. This would include where a file just got moved, deleted, renamed, or otherwise changed somehow, this is kept in mind for the undo feature.
  • Files locally cached to avoid calling server every time. (All the files vs. what has been viewed) NOT the contents.
  • What user has been on which file and when. These are incredibly important details to keep in the database to keep track of what is being changed by who. If someone is maliciously deleting files, it is important to know who.
  • Caching how long the user has been on allows the remote file system to timeout inactive users.

##Out of Scope Some things aren't really meant for this particular class but could still be related to the project as a whole. Here's a brief list of what not to worry about implementing at this stage in development.

  • Security concerns for logging in, such as captcha or number of failed login attempts.
  • Encryption
  • Compression

#Guidelines When creating milestones and issues these things are key:

  • Keep work to be done in issues small, they can tend to be deeper once you get into coding.
  • Issues should be specific enough that somebody outside of the team can understand what needs to be done to close the issue. Including why it should be done is also good practice.
  • Include where code can be found in milestones and issues when its applicable, it leaves less room for guessing.
  • Point out dependencies inside of the issues that would prevent the issue from being finished.
  • If an issue is outside of code implementation be specific on how it will be completed.

Additional Tips for the Class:

  • Collaborate with other teams, duplicating work is unproductive and wastes a lot of time.
  • Get into a ritual with your team on creating milestones and issues, it saves time deciding who is going to do what and lets you work more on participation grades.
  • Document well along the way, the project works with a lot of people who also use your code.
  • Learn GitHub fast, get help immediately if you need it.
  • Centralize communication with our team early, especially if you don't use slack.
  • Leave the project easy for others to pick up.

tl;dr: Read Guidelines and implement some functionality bullet points.