Closed JYamihud closed 3 years ago
The website is probibly not the final one. Your image looks fancy, but I think we should keep it to the information. And there are not multiple pages required. Different Fonts is imo too much, we should the browser decide which font he want.
The source code to the page is open, see https://git.sr.ht/~tenacity/tenacityaudio.org. Everyone can send patches in.
BTW: Currently Tenacity doesn't look different then Audacity. In the moment the changes are only that telemetry, crash reports and other shenanigans are removed.
If the project wants the penetration of Audacity, or even a fraction of it, the user facing side is going to need to be more marketing less geek. Things like pleasing graphics and sites with a contemporary design matter. It doesn’t need to be multiple pages. In fact current page designs use an auto loading scroll to anchor points rather than multiple pages. The more it looks like example 2 the more likely the project is to capture current Audacity users as well as those that are looking for a free editor.
I'm willing to review patches to the website, but I think a couple of things are important:
sans-serif
/monospace
.I think a more appropriate comparison for site design would be GIMP. It’s got the elements to which I referred in the previous post. An even better example is Ardour as it’s an audio program. Both of those styles are commonly used not only on the commercial web but also on FLOSS sites that develop mass market open source software.
A good looking website is important. If we make it look intimidating to the average person, we will not get good user numbers. That means more people using the un-forked version of audacity, meaning more privacy is lost. We should make it easy for the average user. Information first is good, and so is making the webpage as static as possible (no to little JS, if possible. There is a lot you can do with HTML and CSS). The project isn't about passing a website purity test regarding content, it's for getting average people into the driver's seat of the software so they can "take it for a drive" (pardon my metaphor). The site is a form of advertisement for the project that is primary directed at non-technically inclined people. The majority of geeks won't care about the website either way, so long as it doesn't actively get in the way or have a bunch of trackers or anything else that is categorically bad. The average Tenacity user is probably going to be a power-user, not a developer.
A lot of people who will use the fork will use LibreJS. It's a plugin that detects non-free software javascript code and blocks it from running. So making a website without JavaScript. Or with a very minimal use of JavaScript is very important.
I and a lot of paranoid people ( who use GNU IceCat ) have a plugin that blocks all third party requests. For example on AudacityTeam.org website it blocks fonts.googleapis.com
and mc.yandex.ru
. I can enable them if I want, manually. But I don't want to enable them.
An exception to this would be to use spee.ch
with the LBRY protocol for hosting large files. Like videofiles, images, or whole binary builds. You can either get an LBRY Desktop app and upload to there. Which is going to publish this file in a block chain. Also you can use a web-based client for this like Odysee.com. Changing the lbry url to spee.ch, like for example, lbry://@blenderdumbass:f/3-best-audacity-forks:9
to spee.ch/@blenderdumbass:f/3-best-audacity-forks:9
will redirect you to the file it self. So you can do hosting like this.
There are obvious things like LibrePay that can be implemented. But I think a few more ways of getting donations could be added.
Also the LBRY channel could be used like an update article hosting place. Where people can comment. Like for VCStudio
A basic site with text works fine. No need to get overly complicated with it. A consideration should instead be taken to on the security header side of things; the website has no permissions policy to prevent FLoC, no UA-enforced TLS, and no referrer policy.
As I said, another downside of JS, media and selfhosted fonts is load time. I don't understand the problem with a simple page, a couple of images, and links to important resources. It can look pretty, sure, but not at the expense of getting things done.
Not everything needs to be done through the website, too; having one page isn't necessarily a bad thing. If GitHub has a releases page, we shouldn't create one ourselves. We don't need a blog.
There's a difference between making a website eye-catching and making it bloated. Patches welcome.
A consideration should instead be taken to on the security header side of things; the website has no permissions policy to prevent FLoC, no UA-enforced TLS, and no referrer policy.
See this page for sourcehut's full CSP header.
Hey all, see https://github.com/tenacityteam/tenacity/discussions/159 for a no JavaScript, privacy-respecting, yet still well-designed page (disclaimer: I am the author of the design)
Hey all, see https://github.com/tenacityteam/tenacity/discussions/159 for a no JavaScript, privacy-respecting, yet still well-designed page (disclaimer: I am the author of the design)
Looks good. I'm still iffy on the inclusion of custom fonts; if you can get away with using sans-serif
that'd be appreciated.
Custom fonts should be used, but only those that fit with the theme and have good licenses. I personally lean towards IBM Plex Sans in a ton of projects, which is open source under the SIL Open Font License.
We can use sans-serif
and that may be enough, but my alternative solution is to use the free and open-source font Inter on the open-source CDN https://docs.xz.style/fonts/ (which has no tracking). We could embed Inter on a local server as well. If neither option is ok, we can use this css rule:
font-family: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
We can use
sans-serif
and that may be enough, but my alternative solution is to use the free and open-source font Inter on the open-source CDN https://docs.xz.style/fonts/ (which has no tracking). We could embed Inter on a local server as well. If neither option is ok, we can use this css rule:
font-family: ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, "Noto Sans", sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji";
You'll have to check SourceHut Pages' limitations: I don't think they allow 3rd-party CDNs
* Information first: in my mind, I don't want people to browse the website, I want them to use the software. https://systemd.io is a bit of an extreme example, but it shows how something can look good while not being too fancy. Also see https://thebestmotherfucking.website.
http://bettermotherfuckingwebsite.com https://evenbettermotherfucking.website/
@JYamihud They should also accept monero for payments as an anonymous way of donation.
You'll have to check SourceHut Pages' limitations: I don't think they allow 3rd-party CDNs
No problem, just include the Inter woff2 font as a base64-encoded string in the CSS styles.
http://bettermotherfuckingwebsite.com https://evenbettermotherfucking.website/
Yeah, I get that minimalist approach, but I think something like https://starship.rs/ is the superior approach. Right balance of content amount, minimalist design, and some good documentation/info. This is also why I think we should design the website in something like Penpot or Inkscape first, so that we can find the right balance before going full speed ahead with coding the site, only to find it's too much/too little.
No problem, just include the Inter woff2 font as a base64-encoded string in the CSS styles.
- Do we need really a font specifically?
- Base64 encoding, no. At least do it as a file, not a string which is 37% larger than just a file and linking to it.
- It might slow load time.
@Semisol Strictly speaking? No, I haven't needed to use one for a web dev project for a long time. However, that's assuming the user has a decent sans-serif font on their system already. And based on my experience using tons of legacy browsers over the years that is absolutely not a guarantee. If we stick to sans-serif
we run this risk - making the experience likely worse for many users on older systems.
Just submitted a patch, made the text responsive, changed the background to be a bit warmer, changed font colour to match the background and added some meta tags.
Just submitted a patch, made the text responsive, changed the background to be a bit warmer, changed font colour to match the background and added some meta tags. [Image redacted for visibility]
I've sent an updated patch myself, tweaking yours a bit. You're added as a co-author. Could you review it?
Made some changes as well to the styling and layout:
I'll submit a patch if you guys like it, though it is quite a departure from what we had before
Made some changes as well to the styling and layout:
I'll submit a patch if you guys like it, though it is quite a departure from what we had before
Small request before submitting: There is a space missing in the IRC (web)
link, if you could fix that and send it over that would be appreciated. (Also, --signoff applies to the website)
I think this looks good (still don't think the font is special enough to warrant selfhosting), but the actual content is subject to change, as we want to cater to the end-user.
...wait is this sans-serif
There's been a discussion on IRC, and we might want to use openring to generate a feed of the latest tenacity-announce
posts. It's static and JS free.
@SFR-git This IS sans-serif to clarify
@Semisol Fixed:
@Semisol Fixed:
Thanks, submit patch? (--signoff)
Yup, I'll do that, just need to make the nav responsive first (one css rule will do)
Also, for the download button I'm assuming I should link to https://github.com/tenacityteam/tenacity/releases?
Sure, but don't touch any other repo links until #155 is closed and we have a final decision.
Bummer...I don't think I can submit a patch:
fatal: unable to access 'https://git.sr.ht/~songtech-0912/tenacityaudio.org/': The requested URL returned error: 403
(I'm in a country where this happens all of the time. Will have to sort this out)
Ah. That's not how you submit a patch, try this:
git config format.subjectprefix "PATCH tenacityaudio.org"
git send-email --annotate --to="~tenacity/tenacity-dev@lists.sr.ht" HEAD^
Make sure your gitconfig is set to send emails. See git-send-email.io for a step-by-step guide.
fatal: unable to access 'https://git.sr.ht/~songtech-0912/tenacityaudio.org/': The requested URL returned error: 403
The (unrelated) reason to this problem is the fact that sourcehut only accepts pushing through SSH, for security reasons.
Ah, sorry. I was too used to github's way of doing things. Thanks for the advice, will do.
Ah, sorry. I was too used to github's way of doing things. Thanks for the advice, will do.
It's all good :D
Feel free to send the patch to my private inbox beforehand, to make sure everything's fine.
<sol@solfisher.com>
I've sent the patch, you've received it?
I haven't, no.
git send-email
should return 250
if it's been sent correctly.
Would you mind joining the IRC channel so we can help you in real time?
@SFR-git Yeah no problem. However, I am in a country where accessing international sites doesn't work 50% of the time so I'm not sure I can actually join.
@JYamihud OpenCollective or LiberaPay are better options.
An image of the software. Or even better a short video-file demonstrating the use of it ( with sound ) should be used. Just text is not very descriptive of a sound editor. People who will click on the site by mistake, wouldn't get that's a software project, just like that. They have only 3 seconds of attention, and will be able to read the word "Repository". With an image ( or better a video ) they will see what's it about immediately.
@JYamihud Usually I would be inclined to agree, but in this case I wouldn't for a very specific reason - think of the effect if we did add the image. Tenacity isn't great-looking on a screenshot - it looks like something from a decade ago. If a user saw the screenshot of Tenacity, the user would likely have a bad impression of Tenacity as outdated, poor-quality software.
Sent a patch to add dark mode for the time being
The average Tenacity user is probably going to be a power-user, not a developer.
Based on what I've seen in the pro audio/enthusiast Audacity user base are most users are "regular Joe" type of users. Power users are more likely to be using Reaper or Pro Tools if the work is paying work and they need to exchange projects with others in the business. Rank and file users include audiophiles, people in bands, singer/songwriters, podcasters and DJs. Audacity base is largely hobbyist/enthusiast users that aren't audio pros. They're using it because it's free and it's relatively easy to use.
We use Audacity in pro environments as a lightweight, on the fly editor. We've been using it pretty much since it was first released. There are feature limitations that make Audacity a less preferred choice for power user tasks but has its place for basic edits and even some tracking. It's perfect for the new or novice user and a good stepping stone to a more full featured DAW like Reaper.
Hey, I've tried and re-tried several times to send my patch over by email, it has not succeeded so far. Would it be possible to mirror the tenacity website on github so I can send a PR in? I understand that it would be quite a bit of work, but contributions seem much more complex by the patch-only system.
I don't think accepting PRs is the right move. It's too much infrastructure to maintain for one-off problems like this one. Could you export your commits as .patch
files and send them as a gist, or something?
Yeah, that's a good temporary solution. Here it is: https://gist.github.com/Songtech-0912/16c18643a642b3e5d945340402945998
Also, this may be a bit off-topic (and may exist already), but I could do some work on the docs. I've made a simple site generator script in the past to turn markdown files into a full documentation site, if necessary that could be used. It would also be helpful to use the website styles on the docs as well, allowing us to build an identity separate from that of Audacity instead of always being regarded as just another "fork" of audacity.
That's... a really old commit you got there. git am
won't even apply it. Could you git pull --rebase
, then fix the problems?
Current website
This is a very basic text site with a few problems.
Download
andCommunity
.Design 2.0
I made this picture in GIMP in a few minutes. Which already reads like a way better looking website. After features, icons that describe features, with a quick explanation of them, could be added.
We could copy the aesthetic of the www.audacityteam.org site. Or could make it look more like the list. Even a special page for Features could be added. Focusing on latest news on the main page. But then somebody will need to write those news articles.
A pretty screenshot of Tenacity is required. I used Audacity 2.3 for this image. But a true Tenacity screenshot with a true tenacity theme should be the one shown.
Originally posted by @JYamihud in https://github.com/tenacityteam/tenacity/discussions/162