FilePicker: ARK view ("Roots" tab)

[kirillt]

An ARK-enabled folder is either:

• a root folder—any folder containing .ark subfolder
• a favorite folder—subfolder of a root mentioned in .ark/favorites file

Since we use content-addressing, we have special file called index. It is stored in .ark subfolder of each root folder. Favorite folders are children of root folders and don't have their own index, they use their root's index file.

Normally, roots are listed in .ark-roots file in the disk root. If it doesn't exist then we should scan the whole filesystem (Navigator does this on first launch). Each root folder contains list of its favorite folders in .ark/favorites file.

The "Roots" tab lists all ARK-enabled folder: both roots, and favorites. It was implemented in scope of this issue:

• ARK view ark-filepicker#23

[kirillt]

We only need to finish these 3 details:

General points:

• Switch-off ARK view when there is no .ark-roots file
• Remember the active tab, start with the tab which was active last time

File-picking mode:

• Enable ARK view in file-picking mode
  For this we need to implement one of these:
  • Embed Resource Grid from Navigator
  • Allow selecting a folder and switch back to classical view.

[tuancoltech]

An ARK-enabled folder is either:

• a root folder—any folder containing .ark subfolder
• a favorite folder—subfolder of a root mentioned in .ark/favorites file

Since we use content-addressing, we have special file called index. It is stored in .ark subfolder of each root folder. Favorite folders are children of root folders and don't have their own index, they use their root's index file.

Normally, roots are listed in .ark-roots file in the disk root. If it doesn't exist then we should scan the whole filesystem (Navigator does this on first launch). Each root folder contains list of its favorite folders in .ark/favorites file.

The "Roots" tab lists all ARK-enabled folder: both roots, and favorites. It was implemented in scope of this issue:

• ARK view ark-filepicker#23

I just want to correct this a bit: roots are listed in .ark-global/roots file, not .ark-roots :)

[tuancoltech]

We only need to finish these 3 details:

General points:

• Switch-off ARK view when there is no .ark-roots file
  ...

@kirillt And, do we switch-on ARK view when the first root folder is created?

[tuancoltech]

We only need to finish these 3 details:

General points:

...
File-picking mode:

• Enable ARK view in file-picking mode
  For this we need to implement one of these:

...

• Allow selecting a folder and switch back to classical view.

Regarding this, at the moment Roots tab (ARK view) is already visible when open the file picker in FILE mode as per below video. Please correct me if I mis-understood something here.

https://recordit.co/bHtZCodxlW

[kirillt]

@tuancoltech yeah, correct about roots file. Sorry for the outdated info.

About switching on first root — good question. I think we can let the user discover ARK-mode themselves :)

[tuancoltech]

@tuancoltech yeah, correct about roots file. Sorry for the outdated info.

About switching on first root — good question. I think we can let the user discover ARK-mode themselves :)

Yeah, so I'll not switch-on on first root then.

[tuancoltech]

We only need to finish these 3 details:
General points:
...
File-picking mode:

• Enable ARK view in file-picking mode
  For this we need to implement one of these:

...

• Allow selecting a folder and switch back to classical view.

Regarding this, at the moment Roots tab (ARK view) is already visible when open the file picker in FILE mode as per below video. Please correct me if I mis-understood something here.

https://recordit.co/bHtZCodxlW

@kirillt And what do you think about this please?

[kirillt]

@tuancoltech it's ok when user already has ARK-enabled folders in the system. If he/she hasn't such folders yet, we can either:

• hide "Roots" tab and wait until they pin something
• show "Roots" tab with some explanation in it as a placeholder

What is better in your opinion?

[tuancoltech]

@tuancoltech it's ok when user already has ARK-enabled folders in the system. If he/she hasn't such folders yet, we can either:

• hide "Roots" tab and wait until they pin something [1]
• show "Roots" tab with some explanation in it as a placeholder [2]

What is better in your opinion?

@kirillt Currently my local implementation is already working as in [1] for File picking mode.
However, since you mentioned 2 options as above, personally I would prefer option [2] as by that, users won't have to dismiss and re-open the picker dialog for the Roots tab to appear, after user pins a folder.

Please let me know if I should update the implementation if we want to make it work as in way [2].

[kirillt]

@tuancoltech with [1] Roots tab should appear automatically after 1st pin, without re-opening the dialogue. But overall interaction is a bit more complicated. Benefit of [1] in my opinion is reduced cognitive load for users who only started to familiarize with ARK apps.

[tuancoltech]

@tuancoltech with [1] Roots tab should appear automatically after 1st pin, without re-opening the dialogue. But overall interaction is a bit more complicated. Benefit of [1] in my opinion is reduced cognitive load for users who only started to familiarize with ARK apps.

@kirillt I see. So I'll implement it in a way that when user pin the very first root/favorite folder, the Roots tab is switched-on automatically.
Regarding the UX, should we still stick with [1] for now?

[tuancoltech]

@tuancoltech yeah, correct about roots file. Sorry for the outdated info.

About switching on first root — good question. I think we can let the user discover ARK-mode themselves :)

@kirillt: Sorry but I think I need to make this more clear: By let the user discover ARK-mode themselves, do you mean we won't automatically switch-on the Roots tab on first root, but only show it when re-opening the dialog?
If so, does it contradict with your comment here: #51 (comment) ?

[kirillt]

Not exactly. It was about [1] as a whole, the view would be more minimalistic at first, so users won't be overwhelmed. When they pin something, they notice that new tab appears, that's what I mean by self-discovery. This could be more delicate then having a confusing redundant tab from the very start.

After pinning, user should be able to see the effect immediately in any case. Necessety to re-open the picker would be clumsy in my opinion.

[tuancoltech]

Not exactly. It was about [1] as a whole, the view would be more minimalistic at first, so users won't be overwhelmed. When they pin something, they notice that new tab appears, that's what I mean by self-discovery. This could be more delicate then having a confusing redundant tab from the very start.

After pinning, user should be able to see the effect immediately in any case. Necessety to re-open the picker would be clumsy in my opinion.

Thanks. I understand it now.