Skip to content

Conversation

HerveCaumont
Copy link
Contributor

updates index.md, adds page user_workspace_finder.html (as update and rename of user_workspace.md), adds page app_code_server.html (as update and rename of ide.md), adds new page app_jupyterlab.html, adds new page qgis.html, renames ide.png to applicationhub.png, within the instantiation section of the apex_documentation

… rename of user_workspace.md), adds page app_code_server.html (as update and rename of ide.md), adds new page app_jupyterlab.html, adds new page qgis.html , renames ide.png to applicationhub.png, within the instantiation section of the apex_documentation
Copy link
Contributor

@JanssenBrm JanssenBrm left a comment

Choose a reason for hiding this comment

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

Thank you, @HerveCaumont , for the edit. I’ve added some comments, but there are two major points of feedback:

  • When changing page names, please make sure that all existing links to those pages are updated accordingly. As shown in the [PR build page]https://github.com/ESA-APEx/apex_documentation/actions/runs/17244676967/job/48931264995?pr=157), many links are currently broken. This needs to be resolved before we can proceed with merging the PR.
  • The User Workspace Finder feels somewhat out of place among the existing solutions. My suggestion would be to remove it as a standalone item and instead refer to its concepts within the individual pages for Code Server, JupyterLab, and QGIS. This would also align better with the website, where we don’t showcase it as a separate solution.


## Code Server
## Code Server workspace
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggestion to use Title Casing to be consistent with the other titles: "Code Server Workspace"

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Well spotted, and it deserves indeed a discussion / update.
Here it is, let me know how it unfolds for you:

I do not want "workspace" to be part of any App name apart the (upcoming) User Workspace Finder, and I would like to work cross-doc pages to remove any past use of "workspace" as a product name label on Code Server, JupyterLab and QGIS.

And I'd like to be free to use "workspace" or "user workspace" as a qualifier only (denoting a specific capacity).

This follows the logic we have already implemented here:
https://apex.esa.int/services/codeserver
Code Server (product name)
Tailored User Workspace for Earth Observation Projects (subtitle)

For APEx, the notion of User Workspace must become clear as an infra capacity, related to data management and (future) data exchange/sharing only. So, the Code Server app relies on the User Workspace capacity and this provides access to a file system (which, as a user workspace, is indeed secured and private to the authenticated user).

Overall, this "workspace" term is becoming only an adjective to denote a family of Apps handled by the ApplicationHub, that handles the capacity of a file system secured and private to the authenticated user.

Moreover, the ApplicationHub is kept in the doc pages simply because of the specific user-facing Launcher UI of the ApplicationHub. I see no other good reason to mention it to the APEx users. Ultimately, we could consider fully hiding it from the user experience.

of the [Code Server software (Visual Studio Code in the Cloud)](#code-server), and of the [JupyterLab](#jupyterlab) software.
The Geographic Information System (GIS) capacity leverages [QGIS](#qgis) as a Remote Desktop software.
The Code Server Interactive Development Environment (IDE) capacity within the APEx Project Environments primarily leverages the power
of the [Code Server software (Visual Studio Code in the Cloud)](#code-server).
Copy link
Contributor

Choose a reason for hiding this comment

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

When changing the title name, the link to #code-server should also be updated accordingly.


![Current APEx IDE and GIS Services](images/ide.png)
![Current APEx Code Server IDE service](images/code_server.png)
Copy link
Contributor

Choose a reason for hiding this comment

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

Maybe we should remove "service" here as we always seem to use Code Server IDE below.

The JupyterLab Interactive Development Environment (IDE) capacity within the APEx Project Environments primarily leverages the power
of the [JupyterLab](#jupyterlab) software.

![Current APEx JupyterLab IDE Service](images/jupyterlab.png)
Copy link
Contributor

Choose a reason for hiding this comment

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

Same comment as with Code Server, should we remove "Service"?

::: {.callout-note}
There is no GitHub Copilot extension available yet for JupyterLab.

See the Code Server IDE page for more details on CoPilot extensions.
Copy link
Contributor

Choose a reason for hiding this comment

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

Add a link to the page and maybe the corresponding section to support direct navigation.

hosting, execution, and exploratory analysis of EO applications. This flexibility and configurability allow these
projects to focus on their primary research objectives without being bogged down by the technical complexities of
setting up and maintaining their workspaces.
can be tailored to the specific needs of different projects and users for their tasks (EO application development, hosting,
Copy link
Contributor

Choose a reason for hiding this comment

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

I would keep the original text: supporting various tasks, including development,
hosting, execution, and exploratory analysis of EO applications. The modified sentence gives the impression that it is limited to these tasks, which it isn't as the project environment also includes tools such as portals and forums, which go further than creating EO applications.

* [**Product Catalogues**](catalog.qmd)\
* [**User Workspace Finder**](user_workspace_finder.md)\
Offering a secure and personalised work environment with data management and data sharing mechanisms.
* [**Code Server workspace**](code_server.md)\
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggestion to use title casing: Code Server Workspace. Additionally, before we have been calling it the Code Server IDE, which one should we use?

---

## Overview

The User Workspace service within the APEx Project Environments provides secure, personalised environments for individual
The User Workspace Finder service within the APEx Project Environments provides secure, personalised environments for individual
users to perform a wide range of tasks, including development, data processing, visualisation, and analysis. These single-user
environments are managed by JupyterHub and dynamically provisioned using Kubernetes, ensuring scalability, isolation, and
Copy link
Contributor

Choose a reason for hiding this comment

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

JupyterHub or ApplicationHub?

The User Workspaces support a variety of use cases, making them versatile tools for the EO community. Some typical
scenarios include:
The User Workspaces Finder support a variety of use cases, making them versatile tools for the EO community.
Some typical scenarios include:

* **Development and Testing**\
Copy link
Contributor

Choose a reason for hiding this comment

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

I would summarise this and the next sections as a data sharing scenario as they both present the same concept.

@@ -1,10 +1,10 @@
---
title: User Workspace
title: User Workspace Finder
Copy link
Contributor

Choose a reason for hiding this comment

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

The description of the Workspace Finder currently feels somewhat unclear and disconnected from the other solutions presented on the site. As it stands, presenting it as a standalone solution might give users the impression that it offers full-fledged file-sharing capabilities. This could lead to unrealistic expectations, especially since the current data-sharing features likely don’t match what users might associate with platforms like Google Drive or EOEPCA’s User Workspace.

Unless we can provide more detailed information about its capabilities, the Workspace Finder seems better positioned as a supporting technology for services like JupyterLab, QGIS, and CodeServer. In that case, I’d recommend referencing it from the dedicated service pages rather than giving it its own standalone page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants