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

organize by the service, not by the package #492

Open
wibeasley opened this issue Feb 2, 2023 · 6 comments
Open

organize by the service, not by the package #492

wibeasley opened this issue Feb 2, 2023 · 6 comments
Assignees

Comments

@wibeasley
Copy link
Collaborator

@pachadotdev, I like the parts of the task view that first declares the web service (in italics), and then lists the associated packages. Like the Azure section has been.

I tried it out with an are that I'm familiar with (in commit 998e5ae).

image

Do you have opinions?

  • I think it's easier to read because the user likely looks for the service first (and then what packages can help them) instead of looking for the package first (and then what things it does)
  • Linking to the service (like REDCap or WuFoo) helps the reader learn about it, but it increases the burden on us to find the link and maintain it.

@zeileis, are there any tools you recommend for checking urls in CTVs (that are not links to packages). Similar to urlchecker for package development? Like something that what catch a url (eg, "https://curl.se/libcurl/") that has changed?

@wibeasley wibeasley self-assigned this Feb 2, 2023
@zeileis
Copy link
Contributor

zeileis commented Feb 2, 2023

We currently do not have support for this in the package. The reason is that most URLs are autogenerated by the task views and then there is typically only a rather short list of additional links at the end.

Of course, the WebTechnologies task view is different here. One possible way to check this would be to use the functionality from the basic tools package (leveraging curl behind the scenes). It's relatively easy to use albeit unexported, unfortunately.

The first step is to construct a URL "database", simply a data.frame with additional class url_db, containing the URL and information about the Parent document where this is listed. Subsequently, this database can then be checked. For example:

db <- tools:::url_db_from_installed_packages("ctv")
head(db, 3)
##                                       URL          Parent
## 1 https://github.com/cran-task-views/ctv/ ctv/DESCRIPTION
## 2      https://ctv.R-Forge.R-project.org/ ctv/DESCRIPTION
## 3   https://CRAN.R-project.org/doc/Rnews/    ctv/CITATION
tools:::check_url_db(db)

So you could write a function url_db_from_ctv_md() or something along those lines

@wibeasley
Copy link
Collaborator Author

wibeasley commented Feb 3, 2023

@pachadotdev, I experimented with another section. I bolded instead of italicized. Both are ok to my eye, neither are great. I'm open to alternatives.

after:
image

before:
image

wibeasley added a commit that referenced this issue Feb 3, 2023
wibeasley added a commit that referenced this issue Feb 3, 2023
@pachadotdev
Copy link
Collaborator

this is neat!
IDK what do senior members think about this

@zeileis
Copy link
Contributor

zeileis commented Feb 9, 2023

I like prefixing each bullet point with the name of the service. That might make it easier to find a specific service one is looking for.
However, I wouldn't hyperlink each of the services. This makes it harder to spot what are the services and what are the CRAN packages. If users are really not sure what service the R package is for, they have to click on the R package first and then use the information provided there.

@wibeasley
Copy link
Collaborator Author

Cool. I agree it's harder to read. And the hyperlinks (to the service) create more work for us to maintain.

I think the hyperlinks might improve SEO for the task view, but I'm ok with the tradeoff.

How does this look to you guys? Do prefer the bold (first section) or the italic (second section)?

image

wibeasley added a commit that referenced this issue Feb 10, 2023
suggested by @zeileis

ref #492
@zeileis
Copy link
Contributor

zeileis commented Feb 10, 2023

Nice. No strong preference from my side.

wibeasley added a commit that referenced this issue Feb 14, 2023
wibeasley added a commit that referenced this issue Feb 18, 2023
wibeasley added a commit that referenced this issue Feb 19, 2023
pattern: `\*\*(.+?)\*\*:`

sub: `*$1*:`

ref #492
wibeasley added a commit that referenced this issue Feb 19, 2023
pachadotdev pushed a commit that referenced this issue Feb 22, 2023
pachadotdev pushed a commit that referenced this issue Feb 22, 2023
pattern: `\*\*(.+?)\*\*:`

sub: `*$1*:`

ref #492
pachadotdev pushed a commit that referenced this issue Feb 22, 2023
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

No branches or pull requests

3 participants