Improve Share discovery experience

[jerrellmardis]

I don't think the current share discovery implementation is the best for the "10ft environment". Currently, it lists all the users share folders in a Spinner, excludes top-level share folders and does not allow the user to input their credentials before it attempts to auto-discover shares.

Suggestions to improve the experience

• First, give the user a choice on whether to look for shared network folders or enter an IP Address/Name manually. I'm thinking 2 big buttons or icons in the center of the dialog.
• If the user chooses to enter their IP Address/Name manually, then the form would slide out to the left and a new form would slide in from the right. The new form would be similar to the existing form we have now, basically 3 EditText fields and a primary action button of "Add" and a secondary action "Cancel". The second form would also have a back button in the top left of the form.
• If the user chooses to have the app auto-discover files, then the current form in the dialog should slide out to the left (giving the user an indication that they can always go back), a new form would then slide in from the right with an option to choose "Guest" or enter their username and password. Every form going forward should have a Back button in the top left of the form, the primary action button (i.e. Next/Submit) in the bottom right with a secondary action button to the left of it (i.e. Cancel).
• After they've completed the form and clicked the Next button in the bottom right, a ListView with the first level of directories is shown. Clicking on a list item will again have the same animation of the current form sliding out to the left and the new ListView sliding in from the right. The new ListView would list all the directories under the previous directory selected.
• Once the user has either entered an address manually or selected one via the "file chooser" they can proceed with adding the share by clicking "Add".

Thoughts?

/cc @rharter @JakeWharton

[JakeWharton]

I would go directly to share search and provide an option for manual entry. Ideally nobody would ever have to enter a share manually. On Aug 10, 2014 11:00 AM, "Jerrell Mardis" notifications@github.com wrote:

I don't think the current share discovery implementation is the best for the "10ft environment". Currently, it lists all the users share folders in a Spinner, excludes top-level share folders and does not allow the user to input their credentials before it attempts to auto-discover shares.

Suggestions to improve the experience

• First, give the user a choice on whether to look for shared network folders or enter an IP Address/Name manually. I'm thinking 2 big buttons or icons in the center of the dialog.
• If the user chooses to enter their IP Address/Name manually, then the form would slide out to the left and a new form would slide in from the right. The new form would be similar to the existing form we have now, basically 3 EditText fields and a primary action button of "Add" and a secondary action "Cancel". The second form would also have a back button in the top left of the form.
• If the user chooses to have the app auto-discover files, then the current form in the dialog should slide out to the left (giving the user an indication that they can always go back), a new form would then slide in from the right with an option to choose "Guest" or enter their username and password. Every form going forward should have a Back button in the top left of the form, the primary action button (i.e. Next/Submit) in the bottom right with a secondary action button to the left of it (i.e. Cancel).
• After they've completed the form and clicked the Next button in the bottom right, a ListView with the first level of directories is shown. Clicking on a list item will again have the same animation of the current form sliding out to the left and the new ListView sliding in from the right. The new ListView would list all the directories under the previous directory selected.
• Once the user has either entered an address manually or selected one via the "file chooser" they can proceed with adding the share by clicking "Add".

Thoughts?

/cc @rharter https://github.com/rharter @JakeWharton https://github.com/JakeWharton

— Reply to this email directly or view it on GitHub https://github.com/jerrellmardis/Amphitheatre/issues/28.

[jerrellmardis]

Ah, right that makes. So the user would be presented with a screen to either manually enter an address or auto discover network shares as a guest or authenticated user.

[rharter]

Some thoughts relating to @jerrellmardis's ideas.

The current implementation lists only top level shared folders. It doesn't list servers, but the shares that they contain. So in my environment, I have two shares, one for movies and one for tv shows, so that makes sense. Where this breaks down is when you have one share, with nested folders for different content. For now you would just have to enter that type manually.

The challenge I ran into was a UX one. If we show the file choose style tree, which I think would be great, how do we differentiate between the user trying to select a folder and trying to navigate down into it. Solvable, but not imperative.

I agree with @JakeWharton that manually entering the address should be the last resort, and certainly not default.

To your note about authenticating before search, authentication is not required, and would not work, for network discovery, since the idea is that you are scanning all shares on the network. It doesn't make sense that you have a single username/password for all servers on your network. What does make sense is choosing a share (since CIFS auth is per share, not server) then, if it requires auth, requesting it to navigate down into it.

The idea behind the current implementation is to discover shares on the network (could be multiple per server) and let a user select them. If they choose to enter an address manually, then that input appears. Authentication is per share, so they only enter that after they've chosen one (or before, doesn't matter since we aren't doing file tree navigation).

The only way I would really change the current implementation is by adding a file tree chooser that allows you to drill down into a share, but that will take some UX design thought.

[jerrellmardis]

With my setup, I have a NAS with a single share, "Media" which is password protected. The current implementation doesn't find the share if an auth object isn't provided in the SmbFile() constructor. In addition, the direct children in the Media folder are not included in the list that populates the Spinner and these are the ones that I would like to add as a source. The list in the Spinner includes my individual movie/TV Show directories but not the parents. This also breaks down from a UX perspective if a user has a lot of directories and subdirectories. On Aug 10, 2014 3:06 PM, "rharter" notifications@github.com wrote:

Some thoughts relating to @jerrellmardis https://github.com/jerrellmardis's ideas.

The current implementation lists only top level shared folders. It doesn't list servers, but the shares that they contain. So in my environment, I have two shares, one for movies and one for tv shows, so that makes sense. Where this breaks down is when you have one share, with nested folders for different content. For now you would just have to enter that type manually.

The challenge I ran into was a UX one. If we show the file choose style tree, which I think would be great, how do we differentiate between the user trying to select a folder and trying to navigate down into it. Solvable, but not imperative.

I agree with @JakeWharton https://github.com/JakeWharton that manually entering the address should be the last resort, and certainly not default.

To your note about authenticating before search, authentication is not required, and would not work, for network discovery, since the idea is that you are scanning all shares on the network. It doesn't make sense that you have a single username/password for all servers on your network. What does make sense is choosing a share (since CIFS auth is per share, not server) then, if it requires auth, requesting it to navigate down into it.

The idea behind the current implementation is to discover shares on the network (could be multiple per server) and let a user select them. If they choose to enter an address manually, then that input appears. Authentication is per share, so they only enter that after they've chosen one (or before, doesn't matter since we aren't doing file tree navigation).

The only way I would really change the current implementation is by adding a file tree chooser that allows you to drill down into a share, but that will take some UX design thought.

— Reply to this email directly or view it on GitHub https://github.com/jerrellmardis/Amphitheatre/issues/28#issuecomment-51725594 .

[rharter]

That's interesting, since this implementation should just be finding your main share. So in my case, my media server is called MEDIASERVER (all caps for Samba), and I have two shares (folders), Movies and TV Shows. So in the list, I see:

smb://MEDIASERVER/Movies smb://MEDIASERVER/TV Shows

So that we have the same terminology, the format is smb://<server>/<share>.

Those are both password protected, but the name broadcast, you just need a password to connect to them (That's how windows does the discovery, too, from what I've gathered).

I agree that the UX breaks down for subdirectories, that's where we need some sort of tree browser.

[jerrellmardis]

Yea that's weird, I have the same format. I also had to change

domains = new SmbFile("smb://").listFiles();

to

domains = new SmbFile("smb://DiskStation", auth).listFiles();

in order to find my directories. Maybe this is a Synology configuration issue but I'm not sure.

[rharter]

Okay, that explains what you're seeing. The current logic works like this:

Get Domains

Get the available domains on the network. For me, with only one server this just returns a single entry, the default WORKGROUP. But that could possibly be other things.

domains = new SmbFile("smb://").listFiles();

Get Servers

For each domain, get all available servers in the domain. Again, I only have one server, MEDIASERVER, but that could be anything (in your case, should be DiskStation).

// servers = new SmbFile("smb://WORKGROUP/").listFiles();
servers = new SmbFile(domain.getPath()).listFiles();

Get Shares

For each server, get all available shares. These are the top level shares on a server. You don't need to authenticate to see them, just to connect to them, later. In my case, this is Movies and TV Shows.

// servers = new SmbFile("smb://MEDIASERVER/").listFiles();
shares = new SmbFile(server.getPath()).listFiles();

Return only valid shares

The list of shares that is returned will include hidden shares, things like smb://MEDIASERVER/printers$/ and smb://MEDIASERVER/IPC$/. These are for things like printer sharing and are ignored. Other shares (not ending in $) are the available shares on a server and are added to the list.

None of this should require authentication, as this is the publicly available data on a server. That's the same as how your mac can show you the smb shares on a server without you authenticating, but requires auth to connect to that share. Once you try to connect to a discovered share, like smb://MEDIASERVER/Movies, you will need to provide credentials. Thus, if we end up allowing people to select from subdirectories (which we'll need to), we will have to have them authenticate in order to navigate down the share.

[JakeWharton]

Another data point, I have a single share with child folders for differentiating content types. The current search presentation prevents me from using them since it only recognizes root folders of shares.

[rharter]

I guess I'm not as normal as I thought :) I've got an idea for this, I'll work something up and share it soon.

[jerrellmardis]

I'm going to hide the Spinner for now.

[rharter]

So I've got a first pass implementation of this complete, but running into some Samba issues. Apparently there is no reliable way to get all of the Samba shares on the network, as described here.

You can see my working prototype here.

While this worked for me earlier, now I continually get java.net.UnknownHostException: ..__MSBROWSE__.<01>, as described in that mailing list post above.

I've added a part of that that can ping all IPs in the 192.168.1 subnet, but that takes forever, and returns all computers regardless of whether their running SMB or not.

Anyone have any expertise here and want to weigh in on how to discover SMB servers on the network?