> Speculating, but perhaps it needs to be updated once in a while? Last modified might be a (dumb) factor.
It's a fair point. I have over time, such as updating libraries which produced new zip files and also modified lessons. It didn't move the needle for rankings, but it did update the timestamp.
I'd like to start a standard marking of some sort to call them out. A hot pink arrow drawn with spray paint on the pole is the first thing that came to mind.
It's funny because when I saw the Slate, I thought it was cool, but the bed was a bit too short to camp in. And there was a large front trunk, a little too large I thought. If only they could take a bit off the front, and put it in the back.
And then I saw the Telo! Hah, they went too far in the opposite direction. Something between these two is what I'd like.
Ahh, I misunderstood then. You used the acronym FOSS/H, which I interpreted as including both software and hardware.
I like the concept of an "The Ethical Computing Initiative" and am supportive of people adopting that mindset. I think the idea of a unified storefront could be useful for certain audiences. It's not really my cup of tea, but I'm not who you need to be addressing anyway (it would just be preaching to the choir).
Would love to hear any ideas on how to improve the message. So far it has not resonated and we don’t have any feedback as to why.
This particular post seems to have stumbled over the acronym FOSS/H, only chosen because I thought FOSH would not be recognized. I’ll avoid acronyms next time.
Due to the mobile revolution Mozilla has been doomed as a significant player, no matter what they did.
There was one shot however, "Firefox OS" on mobile. Of course they gave up early when they should have been investing in it continuously and plugging that google money away into an endowment instead of leadership salaries. Had they done that they'd at least have a chance now.
Thank you. Though we're looking to start a hardware/support org perhaps, not write a book. There will probably be small editions, but the main ideas have been addressed. ;-)
Anyway, any thoughts about the text, title, etc would be very helpful.
Is it a problem to repost after a couple of days? It isn't spam, and has attracted a dozen votes a few times. Just not enough to start a discussion, which we're waiting on. Really needs feedback to improve and move forward.
We noticed recently that about 90% of the open/free products we need to build an Apple-like product line exist already. Let’s work together to sell and support them.
You realize you don't need input field for file input in any of the modern browsers. Just capture the click event and create input field temporarily.
let i = document.createElement('input');
i.type = 'file';
// other attributes if you like
i.onselect = ev => {
// ev.files contains selected files
};
i.click();
i.remove();
No stupid styling hacks needed. At most you may need tabIndex on the <a> or <div> that represents the button for selecting files.
You can leave <input type=file> around if you want to submit data via <form> and not via XHR.
You clearly never implemented any of the above stupidity with file input styling and overlays and passthrough of events, and different unchangeable widths of file inputs you had to account for in various versions of browsers, and bugs in specific browser versions, and discontinuity in the input field clickable surface so part of the button is not clickable for no reason whatsoever to the user, so that everything works as expected in E6+IE7+IE8+IE9+FF1+Sfari,... to think it's even comparable on the hackiness scale.
That's another issue easily solved by DnD API modern browsers implement. And should probably be done differently with regards to UX depending on whether the clicky part was a button, or a larger upload area.
Frankly, I don't find the original UX of dragging files onto an upload button all that intuitive. So instead I add drop functionality to a larger container in my apps. So if I have dialog that accepts files, users can drag files anywhere over the dialog and the dialog highlights that it accepts drops while dragging.
The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it?
Why does there even have to be a button? I want an API not a button...
> The point being that the file input button doesn’t look like any other button on their website. But hey, why solve a problem when you can force the entire world to accommodate it?
Why don't the buttons on your website look like HIG-compliant buttons on whatever platform the user is using? That's what web chrome looked like back in the aughts and it was fantastic. Apparently you can still do it: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Th....
Question, is the point of HIG-compliance to make everything look exactly the same on a platform? Or is it to nail down some abstract sense of what makes UI intuitive to use?
It seems like people with this viewpoint pay lip service to the latter goal, which allows for trends like Material Design so long as they fit with the guidelines, while really wanting the former, which to me looks like nothing more than tilting at windmills.
I'd post screenshots of our current CMS work, where we have a design staff working earnestly to make everything super-intuitive, but HN doesn't do image management so this discussion will be sadly deprived of examples.
> “The purpose of visual consistency is to construct a believable environment for users… The transfer of skills is one of the most important benefits of a consistent interface, especially for beginning users.” pg. 10
> “…consistency makes it easier for a user to learn new applications; it also makes it less likely that a user who follows habits learned from one application will make a disastrous mistake when using a different one.” pg. xi
The HIG goes beyond simply expressing principles of what makes for a good UI. The consistency in and of itself allows users to develop an intuition and muscle memory for how their computer will work. That intuition is destroyed when different apps look and behave differently. In that sense, it's better to be less intuitive according to some abstract principle if necessary to achieve consistency. It will take the user longer to understand a "more intuitive" UI starting from first principles than to understand a UI that exhibits the quirks embedded in the HIG they already know.
Yeah that looks like it's always going to be fighting an uphill battle when it comes to the web. Native apps, certainly. But without an order of magnitude more professionalization of the workforce such that they can fight against business and popular trends, we're stuck with what we have.
This will never work because each browser has its own idea of how native controls should be rendered, even within the same platform. The link you posted even has examples of this. I'm all for the idea of using OS-native controls where possible, and for native apps you should absolutely do this, but I just don't think it's feasible on the web; I believe making your controls consistent across browsers is a better goal in most cases, as long as you don't sacrifice accessibility.
Is that a problem with the file input button, or with every other button on your website?
The file input button does seem to be a barely remembered feature by browser builders. It's weirdly specific, doesn't work the same way on phones, and probably only hangs around because there isn't a decent alternative.
IIRC correctly, the File Input button was deliberately excluded from CSS styling, as it was felt that it would be abused to 'steal' data from clients, if the user wasn't aware it was file upload...
reply