That's good reasoning that I've thought about too. For me, the warning is just as noticeable below the editbox, but you're right it's timing is more appropriate before writing the message.
Both positions are reasonable and my primary concern is to occupy less space with it. If you would minimize the huge vertical padding and lower the horizontal padding to 1em, it would be less in the way to see the original comment. On a wider screen than the screenshot, it would fit into one line, further reducing the impact.
There's an experimental dark theme overlay for those interested: https://www.mediawiki.org/wiki/User:Aron_Manning/Skin_themes
Supports Timeless and Vector skins as of January 2020, Minerva and the 2 oldtimers in the future.
Removed the bar
Mon, Jan 20
That's a nice idea! When the article scrolls down, the article title could be shown there too.
Please explore the idea of moving the warning directly above or below the buttons, reduce the vertical padding to about 2px and the horizontal to 1em. As it stands now it takes up significant, valuable screen space and turns it into empty space between the editors and the responded comment that we wanted to keep close together. I'm sorry to repeat my previous comment, it might have been missed.
Sat, Jan 18
This RfC might have been closed and I've had missed it, however, I haven't found a follow-up discussion, therefore I hope this comment is fine here.
I endorse @ppelberg's answers to these questions.
- I think the warning is the best placed between the preview and the submit-cancel buttons. Possibly on one line, if there is no legal disclaimer (about freely licenseing the contribution). In that place it will be immediately visible when the reply editor opens and still visible before the final decision to submit the comment.
- Thinking: When I finish writing a comment, I move on to the preview (below) to check the formatting, then move further below to click Submit. Before I make that decision (after which there's no revert), it's best that I'm reminded if I have forgotten to log in and I'm about to disclose my IP.
By making an account. No IP editing on phabricator. If this is related to the scroll-up bug after viewing and closing an image, then you could link to the Help Desk request, or tell them the fix is under review, which might take weeks.
If the request is from a MediaWiki operator in dire need of a fix, with the necessary technical skills, they can check out the fix into a folder with:
mkdir MultimediaViewer && cd MultimediaViewer git clone "https://gerrit.wikimedia.org/r/mediawiki/extensions/MultimediaViewer" . git fetch "https://gerrit.wikimedia.org/r/mediawiki/extensions/MultimediaViewer" refs/changes/76/560576/14 && git checkout FETCH_HEAD
and use that folder as the htdocs/w/extensions/MultimediaViewer folder by symlinking it or replacing it. At their own risk only.
Fri, Jan 17
The Great Wall of Text above might be easier to read on-wiki: https://www.mediawiki.org/wiki/User:Aron_Manning/Which_web_framework_to_choose
When choosing a framework, the most important in my view is that the chosen framework be tailored to the specific needs of the project and the community's experience. I think this aspect should be explored in detail as well, so in the next 1 or 2 decades (until these frameworks are superseded and we have this discussion again), we get the best out of the chosen framework.
Hiding the "2 more paragraphs" is a great idea. With a slow transition, when it is hidden...
I find the (blue) border between the editor and the preview important. The scrollbar above a certain size (1/3 or 1/2 screen) looks good.
@Prtksxna have you looked at the patches I've submitted? Those are fairly trivial. Is there something wrong with it?
The patch passes the QUnit and Selenium-Cucumber tests. It's ready for hands-on testing.
If it gets accepted, will there be an internal test period on beta before it goes live?
Thu, Jan 16
Wed, Jan 15
Tue, Jan 14
Mon, Jan 13
Sat, Jan 11
Patch is up, grunt test passed locally.
That's a good option too. Is it correct to say that's the "preview below editbox" variant with the border between the two removed + a darker background to distinguish the preview?
I feel the difference should be more accentuated (a tiny bit darker background) and/or possibly a sublime border that's hardly noticeable. On this preview, I have to think twice which text can be edited.
It seems to me this is a styling question - one worth exploring, to more intuitively communicate the tool's usage.
Fri, Jan 10
Re: preview iterations
Thu, Jan 9
Thanks for the previews, great work!
@Niharika for effectively using the checkuser it would be important to also present the subnet/ISP the IP belongs to. I've suggested adding this to the design 2 months ago in T237593#5643299, but there was no discussion about it since then. I reckon if this is not done now with the fundamental design work, then it won't be done in the coming years. This is the best time to make that part of the design.
@matthiasmullie Yes, I've completely removed the need to restore the position, also removing in the process a number of re-layouts, the jump to the top and back. That noticeable jump, the delay all got removed from the user experience. It is an extensive refactoring / cleanup. I expect it to be more reliable and smooth than getting the timing / order right, which can break for unexpected reasons.
Thu, Jan 2
Wed, Dec 25
The above patch separates the MediaViewer's scrolling to the overlay (body > .mw-mmv-wrapper) element and disables scrolling on the body with overflow: hidden, thereby eliminating the need to hide the content with display:none on open and to restore the scroll position on close. Restoring the scroll position produced a noticeable, disturbing jump to the top of the content and back and depending on browser and CPU load it failed as the content was not laid out in time.
Mon, Dec 23
Dec 16 2019
Dec 15 2019
Dec 12 2019
- I think "Browser-local time" should be a preference for "Time zone" and used only if that's the chosen setting. Could be the default setting, though for new users. Disclosure: I use UTC, not local time (possible bias).
- Currently there's only a "Fill in from browser" option, that grabs the browser's time offset (that includes the current day-light saving) and stores as a setting. That setting does not follow day-light and timezone changes, therefore it's not really useful.
- I often copy the date-time, including timezone to refer to specific comments/diffs or to search for the time in the history. For these usages consistency of the comment timestamps and history timestamp is important, both should follow the wiki preference.
- Showing the relative time by default and the absolute time (wiki preference / UTC) on hover is common in messaging software and quite convenient in Flow. However, the tooltip popup solution of reddit is not so convenient imo.
- It would be a nice feature to have with a setting that enables it (could be enabled by default for new users). Note: I actually don't use it, but I know editors who have some script to do this for talk page comments.
- The user should be able to easily select and copy the absolute time. If the presentation changes on hover, there should be some padding to allow for the mouse pointer to move past the last character. Currently, in Flow the user has to stop moving the mouse precisely after the last (first) character.
- Communicating using UTC in global communities is common. There should be an option to show the time in UTC zone on hover, regardless of the wiki preference and whether relative time is shown by default.
Will this be rolled out on en.wiki without an RfC [...]?
Dec 11 2019
@DannyS712 I've looked at the patch set. Please correct me if I'm wrong: as I see you've implemented the "make comment-only entries in block logs" proposal, that adds a new entry without modifying previous entries, thus only the user's visible block reason is changed. I don't see any changes to the block log (Special:Log/block) in the patchset, therefore the previous log entries (and the annotation entries) are all visible there, unmodified.
Dec 10 2019
Dec 6 2019
The "Submit" button brings up the "Preliminary check" tab. As I understand the purpose of that is to not run the actual check (thus no cu log entry created). The first query is run when the "Compare" or "Timeline" tab is opened. I think the UI workflow is a bit confusing, as there is no big button that actually runs the check, or I am misunderstanding the proposed workflow.
I used the wrong word "investigation", I meant "check". An investigation might require more checks. I'm editing that comment to fix this.
I'm going to explore tokenizing/signing the request. It looks like we are already using a JWT library in production so I can't imagine why it would be an issue to reuse that.
Dec 4 2019
A few thoughts on the implementation:
Persistence across tabs -- PHP sessions are stored per browser (not tab) so they persist across tabs. Is that okay?
Dec 2 2019
Nov 21 2019
Parsing looks good. Reliable enough for the purpose: only distinguishing different agents, versions, OSs is important, 100% accuracy is not needed.
WhichBrowser returns more detailed version numbers, that's a plus. Stores patterns in php files.
DeviceDetector stores its pattern data in yaml and requires a yaml parser, thus it can be expected to load slower.
As a non-wm CU my order of evidence strength is (decreasing):
- obviously fabricated UA (uncommon, only trolls do that), 2) same UA 3) browser version increased (updated) 4) same device and OS, different browser 5) different UA
The strength of the CU match adds up with the strength of the IP match:
- same IP in a short timeframe or static IP 2) same subnet, if there aren't many users from the subnet/ISP 3) if accounts use IPs from random countries, that's unlikely to be due to travel 4) IPs reported as proxy/vpn
@JJMC89 Yes, requiring a link to the cause is unnecessary for private/small wikis. Thanks for mentioning this.
It only matters on wikimedia wikis, where there are strong guarantees of privacy.
@Niharika It can be enabled with a flag in the configuration.
Nov 20 2019
The full UA can be displayed as a mouseover popup of the "Browser" field (title="<UA>") and also copied to the clipboard for further analysis when the field is clicked.
Whenever pattern-matching the UA fails the "Browser" column can display "Unknown", or the first ca. 20 characters of the UA with a different color. The user will mouseover to see the actual UA.
This might become tedious if there are more, that failed parsing, eg. more than 3. In that case (or in all cases) an extra column can be shown with all the full UA strings.
This column will likely overflow the screen and require horizontal scrolling.
@Niharika the field is short for a textual description and a link. Either a longer 2-line textfield or 2 fields would be enough.
In any case, the comments should instruct to paste the link to the cause and form validation should check its presence.
The check is a bit simpler with a separate field, but it is less busy with one longer field.
Nov 18 2019
The cause of doing CU is often an SPI or a user request or suspicious edit. In any case, the reason should link to this cause and the form should require this link for the reason.
Would a separate field for the link be better or a two-line reason field?
With two separate fields I think it would be cleaner:
Nov 16 2019
3 suggested improvements to the partial blocking UI:
Nov 8 2019
Imo CheckUserTest or CheckUserDev or CheckUserAlpha. I assume when it goes to production (new version enabled in config) it will replace the current CheckUser and this in-development name will be dropped.
Nov 7 2019
Besides subnet (whois) and geolocation, presenting Proxy/VPN data would be useful for CU. Example: https://www.ipqualityscore.com/free-ip-lookup-proxy-vpn-test/lookup/18.104.22.168
This data is no more reliable than Geoloc data, yet it is a good clue for determining the likelihood of a proxy user.
^^^^ For description.
A more substantive task.
Add 3 columns: Subnet (name and ip range of the subnetwork), Geolocation (closest city, generally), Proxy/VPN (reported/detected proxies)
This would greatly increase the efficiency of recognizing IPs from around the world (VPN users), dynamic ips on the same subnet, open proxies/free VPNs, etc.