The mockup looks good to me. I think we could reuse our local Changelog page for the "View Changelog" item. That is, we could load that one instead of making a request to a remote page (which would need to be kept in sync with the Changelog we ship).
The mockup looks good to me. I think we could reuse our local Changelog page for the "View Changelog" item. That is, we could load that one instead of making a request to a remote page (which would need to be kept in sync with the Changelog we ship).
Agreed! what is that url nowadays? We can style it to match the styleguide and we could be done. Do we have an .onion for it too?
The mockup looks good to me. I think we could reuse our local Changelog page for the "View Changelog" item. That is, we could load that one instead of making a request to a remote page (which would need to be kept in sync with the Changelog we ship).
Agreed! what is that url nowadays? We can style it to match the styleguide and we could be done. Do we have an .onion for it too?
What do you mean? I was talking about avoiding a remote URL and using a local one instead. Today we have about:tbupdate we could split that up and create a new URL, say, about:changelog or something for the "View Changelog" item.
Today we have about:tbupdate we could split that up and create a new URL, say, about:changelog or something for the "View Changelog" item.
Sorry for the confusion, you are right. Having something like about:changelog is ideal. So, we can have the same layout we have in about:tor at about:tbupdate but with a new title.
And then, advanced (and curious) users can go deep on the changes clicking on View Changelog.
Do we need a mockup for about:changelog? is that markdown/markup?
Orthogonal: Do you think we need/should have a place to have it on our website? I think that could be useful to 1. have release notes outside the blog 2. have a centralized place to look for this notes.
Today we have about:tbupdate we could split that up and create a new URL, say, about:changelog or something for the "View Changelog" item.
Sorry for the confusion, you are right. Having something like about:changelog is ideal. So, we can have the same layout we have in about:tor at about:tbupdate but with a new title.
Yes, something like that.
And then, advanced (and curious) users can go deep on the changes clicking on View Changelog.
Do we need a mockup for about:changelog? is that markdown/markup?
Dunno. I have not thought about how fancy we want to have it. My first intuition is to just "cut out" what we have on about:tbupdate today and display it similarly on about:changelog...
Orthogonal: Do you think we need/should have a place to have it on our website? I think that could be useful to 1. have release notes outside the blog 2. have a centralized place to look for this notes.
Kathy and I are starting to look at implementation for this ticket and we have a few UX questions:
Should the post-update about:tor page that includes the Tor Browser has been updated text be displayed one time and one time only? We assume the answer is yes, but that does mean there will be no way for the user to return to that variation of about:tor once they close it or navigate away.
Should we include the For the most up-to-date information about this release, visit our website. text and link on the new about:changelog page? Kathy and I think we should so that users can access that link in the future by opening about:changelog (after they close or navigate away from the post-update about:tor page).
Should the top-right corner of about:tor always include the View Changelog link, or should that only be visible in the post-update about:tor page? Always including it seems preferable because that will provide a way for users to see the changelog later from within the browser.
Exactly, you right. One time and one time only. Next time they open the browser, or next time they open about:tor we should have the regular about:tor.
Yes! about:changelog is the place where we are going to list change log lists. We discussed with Geko the possibility of including it in some place of the website. I owe that ticket. But, it is not related with this ticket scope. Maybe, that copy needs to be updated as well, since we are not going to link to the website, yet. Any suggestion?
I think that we should include it always. Could we keep it?
Now my turn :)
Do you need a mockup for about:changelog? Is that html/markdown? Do you want to put the data there and could I work on the style? Let me know what is better for you.
Yes! about:changelog is the place where we are going to list change log lists. We discussed with Geko the possibility of including it in some place of the website. I owe that ticket. But, it is not related with this ticket scope. Maybe, that copy needs to be updated as well, since we are not going to link to the website, yet. Any suggestion?
The old about:tbupdate page links to the blog posting for the release. I think we can keep that for now. Since the URL is retrieved from a server during the update process, it will be easy to change it later if the website gains a nice changelog page.
I think that we should include it always. Could we keep it?
Yes, will do.
Now my turn :)
Do you need a mockup for about:changelog? Is that html/markdown? Do you want to put the data there and could I work on the style? Let me know what is better for you.
Any monospace system font is elegant for the changelog copy. Then, you already have our brand font loaded. What do you think?
Given our current process, it seems risky to depend too much on the format of the ChangeLog.txt file (we would need to parse it to pull the version and release date into separate fields). But we will try to style the page in a way that is similar to what you propose.
I am not sure if the about:changelog page is a good place for that link. about:tor seems like a better place, and in fact we already have the Tor Browser Manual link there. Maybe we should make sure the manual includes info on how to get help and how to report a bug.
I am not sure if the about:changelog page is a good place for that link. about:tor seems like a better place, and in fact we already have the Tor Browser Manual link there. Maybe we should make sure the manual includes info on how to get help and how to report a bug.