Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make docs more clear #149

Draft
wants to merge 77 commits into
base: main
Choose a base branch
from

Conversation

kokofixcomputers
Copy link
Contributor

Added up-to-date images and summarized some docs. Still updating

@@ -1,6 +1,6 @@
# Appearance Settings

Sandboxie Control > Sandbox Settings > Appearance:
Sandbox > Sandbox Options > General Options > Box Options
Copy link
Collaborator

@isaak654 isaak654 Jan 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this is a good idea, there would be consistency issues with other Sandboxie Control references and Classic users may be disoriented.

It would be better to create a distinction from old to new, for example:

Related Sandboxie Control setting: Sandboxie Control > Sandbox Settings > Appearance

Related Sandboxie Plus setting: Sandbox > Sandbox Options > General Options > Box Options

I would also suggest to restore the Sandboxie Control images you have removed in this PR*** in order to do this:

Sandboxie Classic:

image1

Sandboxie Plus:

image2

but only where you already have the ![](../Media/anyimage.png) tags.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

***More specifically, I think it makes sense to remove the Sandboxie Control images below only after discontinuing Sandboxie Classic, not before. But this decision can only be made by the Sandboxie maintainer.

Media/AlertPrograms.png
Media/AppearanceSettings.png
Media/ForcedProgramsSettings.png
Media/InternetAccessSettings.png
Media/MessagesFromSandboxie.png
Media/ViewMenu.png

Content/AutoDelete.md Outdated Show resolved Hide resolved
Content/BoxRootFolder.md Outdated Show resolved Hide resolved
Content/OpenClsid.md Outdated Show resolved Hide resolved
PlusContent/imdisk.md Outdated Show resolved Hide resolved
PlusContent/privacy-mode.md Outdated Show resolved Hide resolved
PlusContent/BoxSnapshots.md Outdated Show resolved Hide resolved
PlusContent/supporter-certificate.md Show resolved Hide resolved
PlusContent/supporter-certificate.md Outdated Show resolved Hide resolved
PlusContent/privacy-mode.md Outdated Show resolved Hide resolved
Content/AutoDelete.md Outdated Show resolved Hide resolved
@kokofixcomputers
Copy link
Contributor Author

@DavidXanatos Please review this

Content/AlertProcess.md Outdated Show resolved Hide resolved
Content/AlertProcess.md Outdated Show resolved Hide resolved
@kokofixcomputers
Copy link
Contributor Author

kokofixcomputers commented Jan 8, 2024 via email

@isaak654 isaak654 requested review from offhub and typpos January 8, 2024 20:17
@isaak654
Copy link
Collaborator

isaak654 commented Jan 8, 2024

But this repo focuses on sandboxie plus

The main repository sandboxie-plus/Sandboxie still publishes Classic releases. Moreover, currently SbieCtrl.exe is in the Sandboxie Plus installation folder.

I don't think it's the case to drop Sandboxie Classic documentation references given the current state of things.

@typpos
Copy link
Collaborator

typpos commented Jan 8, 2024

Sorry, isaak654, but I don't have much time these days to help out. A few opinions based on a brief scan and a look at the Sandbox > Appearance tab:

  • Classic needs to be documented so long as it exists
  • Keep Classic docs separate to SB+. It's tiresome for users to skip over documentation paragraphs or images that are not relevant to them, and hardly anyone will use SB+ and Classic concurrently.
  • Keep as much information as possible in the application itself. For example, explanations for drop-down-list-options in the "Sandbox > ... > Appearance") page can be shown in the dialog itself as a text label.
  • Avoid using fluffy filler-phrases, like "... can be conveniently managed ...". I think SB users are fairly technical and tend to go straight to the point.
  • Clean up application dialogs before documenting them. For example, "Appearance" tab layout/sizing.
  • Document what is important/hidden/difficult to understand, not what is obvious. For example, the "Appearance" tab shows an option to select what to do when the user double-clicks a box name. This turns out to be a drop-down-combo, not a drop-down-list. You can enter any command in there, eg, "cmd.exe", which will then be executed when the user dbl-clicks the name of the box. Is that documented? Should that really be a combo box? How can a user understand this from looking at the app dialog alone without documentation? I think it'd be better as a drop-down list with a separate text field (enabled/disabled depending on drop-down-list state) to let the user enter the command, and the dialog needs some text to make it clear the option exists. All this before documenting it in a separate place.

Again, opinions only. Ignore me!

@isaak654 isaak654 added the stale Marked as stale label Jan 8, 2024
@isaak654 isaak654 marked this pull request as draft January 8, 2024 23:01
@isaak654 isaak654 added stalled work Progress stopped due to uncertainty and removed stale Marked as stale labels Jan 8, 2024
kokofixcomputers and others added 2 commits January 21, 2024 16:35
Co-authored-by: isaak654 <isaak654@users.noreply.github.com>
Co-authored-by: isaak654 <isaak654@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stalled work Progress stopped due to uncertainty
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants