1. Take the files and figure out what to do with them so they can be read. This isn't a hard problem.
2. Ask everyone affected to email you the photo or a new photo of the documents. We'll just take it on trust that you do so honestly because there's no way you would've seen this coming.
That's not what happened at all. The college board admitted their fault and are letting students take the test again. Even without that, they mentioned in their FAQ that JPEGs and PNGs are the only file types acceptable and even sent out a tweet (which should have been an email) a week before especially for iPhone users to let them know how to take pictures as JPEGs.
I agree with the people blaming the board for not having a standard image input field that lets the OS know when to convert images to JPEG but that is their only fault and I wouldn't have thought of that as a bug deal if not for this issue. While I'm all for open source media formats replacing what we have, HEIC certainly isn't big enough to be considered as among standard input options. Also, isn't Apple themselves infamous for not supporting certain formats throughout their devices?
Emails, tweets, texts are no excuse for broken products. The iPhone is the best selling model in the United States. It is on College Board to support its default image format.
Good product design is owning your users' success. It is not sending people workaround emails.
The bare minimum would have to be to do a warning before every single AP test about this and giving students a few minutes to change their default image format. Sending a tweet (!!!) out does not count as doing any work.
This is a failure. An abysmal failure.
Seriously, fuck Apple. It took legal changes in the EU to force them to the "Just f'ing support USB-C like the rest of the world instead of making half your money selling dongles".
Perhaps Apple should make it easier or automatic to convert into a format that's universally usable.
Bet the same thing would have happened with webp images too.
JPG and PNG are like the FAT32 format of images. Always accepted, everywhere.
Apple was early in supporting the standard. Windows, Android, others have followed. More to come.
When venting one's spleen, it's best to be at least a tiny bit correct.
Further down this thread you’ll see that the board have messed up and they aren’t accepting images they should due to poor implementation.
“ oefrha 1 hour ago [–]
Tried a standard input tag with the proper accept attribute <input type="file" accept="image/jpeg,image/png" /> Selected a HEIC file from Photos in Safari, the selected image was automatically converted to JPEG”
If the latter this is a roaring success.
I'm not saying you are wrong- sure you can argue that it's the iPhone that is broken, from a non-standard format. However, if you are designing an app that needs pictures to be taken and about 45% of your customers (the students) can't just take a picture without going through some conversion while on a time sensitive test- then you majorly fucked up.
End of the day this is on the AP designers for not adding a format which 45% of their base will use by default.
Apple's approach of automatically converting images at the edges is the right way to go. It does require your software to be explicit about what media formats it understands. This is where the College Board failed.
Still, what matters is the reality of the situation. They could have easily made it so that uploading or transferring images, especially to websites, uses a standard format that 99.9% of websites support, instead of one that virtually noone supports (yet).
And at the same time that Apple rushes to support this new standard without providing a good backwards compatible experience, they've been dragging their feet for YEARS on Safari support for progressive web app features that would let devs build truly feature-comparable web apps without being beholden to the App Store walled garden.
If you are developing an application/website and it doesn't work with 50% of your market share- then you are a dumbass for not implementing it.
ESPECIALLY for an AP EXAM with consequences.
This isn't like "oh no, 50% can't reach our site about cat videos". This is an EXAM.
Honestly cannot believe people on here defending them not adding simple image support for 50% of the testers...
Before then iPhones used the 30-pin connector, backwards compatible with 5-year-old iPod accessories. At that time other manufactures seemed to be shipping different barrel-plug chargers and proprietary cables for every model.
So that's 2 connectors introduced over a span of 18 years supported by dozens of product models that sold billions of units. Cables have been available from third parties for most of that time. The only dongles that might apply are 30-pin to Lightning or USB-A to USB-C.
The 30-pin's raison d'être was to provide features you couldn't get out of USB, like analog audio and video out. And Lightning was a much better designed connector than Micro USB due to being reversible, which informed the design of the Type C connector.
I'd agree that the Mac now has a dongle problem, but it's precisely _because_ it switched to USB-C, as you suggested.
That said, come on College Board. Fix your crap. What a stupid bug.
Some scanners even will do the conversion to JPG for you, because they know nobody accepts TIFF files.
If Apple does it, then everyone has to accept it?
And why? Because images are large and Apple's trying to reduce the size on the phone? How about giving everyone more than 5GB of iCloud storage in 2020? Google gives you 10-15GB for free, and costs half as much for more storage.
For premium-priced devices, this is absurd.
And it you want to talk about incompetence, I'd say pushing a format that is almost guaranteed to be incompatible with the millions of existing backends out there is profoundly stupid.
Apple should convert to JPG or PNG when exporting the image to anywhere anytime.
The same problem happens with webp images too - totally unusable almost everywhere, even in photoshop.
Apple wants to reduce storage space photos take up. Fine - but they should convert back to a standard format when exporting the image to be used on some other system.
With that said, it seems the issue is from students that didn't upload the image from their phone (where Apple correctly converts to JPG), but rather transferred the image to their computer, then uploaded into the AP Exam.
If that's true, then this is absolutely on Apple. Why would they export in a format that literally nobody else supports. What are these people supposed to do with a folder full of HEIC formatted photos, that can't be uploaded anywhere else, edited with any program, or opened even opened on some Operating Systems?
Apple should assume nobody else uses HEIC because... well, nobody else uses HEIC.
Generally, when I've worked at places that were not startups a week to get something pushed in to fix something was not reliably enough time.
I didn't see in the article anything about how long they have been aware of the problem, perhaps they became aware of the problem just before the testing was scheduled to start. I guess that is a problem with their QA system, but at any rate I can think of lots of ways that they could have a problem for a week (or even longer really), not be able to fix it in their particular system, and have to notify people.
Of course I agree they did a lousy job of notifying people.
To clarify: It has the best selling model, but it is not the most used mobile OS among US mobile phone users.
At the very least, a message that appeared at the time that one attempted to upload the image with instructions on how to fix the problem on the spot. How hard could that have possibly been?
Yeah, no. Absolutely not. All of the testing for their platform would have to be redone, and if a bug is found, then what?
You can argue that they should have done a better job notifying users, but to argue that "of course they had time to push a fix in the week before the most important testing period" is just nonsensical.
[1] https://gs.statcounter.com/os-market-share/mobile/united-sta...
This isn't a small agile organization, it's enormous and may not have any route to get a patch out in less than a week due to QA requirements. (That isn't to say such slow deployment processes are good, but they do exist and may be contractually required)
I also really dislike Apple's usual "my way or the highway approach" (it's causing my nephews serious issues since some of their remote learning tools use flash which Apple refuses to support) but in this case they are using the right approach to make it a smooth transition.
They may also get some other benefits from this bad/loose heuristic, e.g. hiding Linux's common FAT32 /boot partition; OEMs' "backup" and "BIOS update" partitions; OS Recovery partitions from unknown (and therefore unpredictable-in-approach) OSes; etc.
What the consumer OSes really need is a bit in each MBR/GPT partition's bitflags, that has a meaning equivalent to one of those "no user-serviceable parts inside" stickers. I think it's too late to fit that bit into either standard, sadly.
By "raw octet stream", I meant that the client should upload a file named X made of opaque bytes 0xABCD, as a file named X made of opaque bytes 0xABCD; rather than assuming a higher-level intent on the server's part to acquire some abstract document, where the client would be able to better serve that request by transforming its file to a different file-format.
I didn't mean that e.g. the client should avoid using Transfer-Encoding compression during the HTTP POST request, or anything like that. (That is, after all, a fact about the wire representation of the request; it doesn't affect the file received on the server end.)
Or, to put that another way, an <input type="file"> with no `accept`, is to the client, as `Cache-Control: no-transform` is to the server: an expressed desire to get some specific data that exists the other end sent over "as it is", rather than to get something customized to the peer's needs.
Ask me how I know.
If they still had the uploads they could go back and convert them properly and apologize for the delay.
It's just bad engineering all around. Even if there was a less glaringly obvious bug that caused parsing to fail, how would they debug that parsing bug without a sample file?
It’s hard to call something an “open standard” if anyone who wishes to use it needs to license patents from nokia.
(https://en.m.wikipedia.org/wiki/High_Efficiency_Image_File_F... under “licensing”)
That's really not Apple's problem. Flash Player is dead. Adobe has declared that all support for the plugin will end in December 2020, and every major web browser has indicated that they intend to discontinue support for the plugin in advance of that date. Some desktop browsers (including Chrome and Firefox) have already disabled Flash content by default, and the Flash plugin for Android was discontinued in 2012.
I thought you were suggesting that images should be sent as raw octets for the image, rather than picking a compression format. But that raw data is extremely large, and therefore would have horrible impacts on bandwidth and latency.
That said, you're right. Trying to be clever about what people are sending results in a lot of hidden complexity and bugs of various forms.
Fun fact: iOS users generally do more browsing, so this has a tendency to skew stats like StatCounter.
Examples:
https://www.counterpointresearch.com/us-market-smartphone-sh...
https://www.statista.com/statistics/266572/market-share-held...
New formats are a good thing, and fast adoption of them is good for users.
That's an interesting (and slightly misleading) way to present that statistic. Apple has the best selling models, but does not have the majority of the market by operating system, which is what matters here. It's close, but Android is still supposed to have over 51% of the US market.[1] (If the graph itself is occluded, see the summary below it).
> It is on College Board to support its default image format.
It's a minority platform. It's only a slight minority, but it is one. If you want to make a case that they should support any default format for a platform over a certain percentage of usage (or "almost half"), that's fine, but you can't rely on the obvious argument that it's the dominant platform and thus should be supported, because it isn't the dominant platform.
Edit: Whoops, forgot to include citation
1: https://www.statista.com/statistics/266572/market-share-held...
A file input tag with no accepts attribute when you're expecting a particular type of file is broken. Would Android phones be "majorly fucked up" if they stored images as WebP by default?
[0]: https://github.com/nokiatech/heif/blob/master/LICENSE.TXT
[1]: https://www.mpegla.com/wp-content/uploads/hevc-att1.pdf
So is COBOL[0]; that doesn't mean you should ever use or support it.
If something needs a licence, it isn't open. I mean, it literally doesn't meet the definition of open.
What's more, if the standard was open, then that would be great, but adopting it so soon and setting it to be the default is woefully shortsighted.
At this point though, Flash is known to be dead and buried and folks that haven't migrated off of it have made their own beds[1].
1. ...And unfortunately caused a lot of headache for quite a few parents with multiple children that are trying to let all their children learn concurrently on different devices they have around the house.
What are you referring to when you say "when Apple killed Flash"?
The big outcry was back when Apple made it clear that they would never add Flash support to iOS. But that support never existed in the first place -- one can hardly "kill" something which was never alive.
Desktop Safari still supports Flash, for now. It's off by default (with a "click to enable" icon), but that's no different from how it's handled in other browsers. All signs indicate that they intend to remove Flash support with the next major release, but that just puts them on the same track as everyone else.
A USB accessory will work on any device, but a lightning accessory only works on an iPhone, to nobody's benefit but Apple. Apple's hate of standards is anti-consumer, and that's why the EU ruled against them.
What particularly ircs me is that Apple has acknowledged that USB-C is the superior plug by going all in on their laptops. But they can't let go of all the money they make selling licenses for third party cables on iPhones.
Lightning was a huge win for consumers because it was years ahead of the incompetently designed clusterfuck that micro-USB was.
> Apple's hate of standards is anti-consumer, and that's why the EU ruled against them.
Apple’s “hate of standards” is in part the reason the USB-C ecosystem exists today. They contributed quite a bit to its development.
The EU ruled against Apple because the EU is full of bureaucratic idiots that care more about looking good than actually knowing what they’re doing. The circlejerk that the EU is always correct needs to end.
If the EU ruling happened a few years ago we’d never have had Lightning and we’d have been stuck with the piece of shit known as micro-USB. Thankfully, Apple was allowed to innovate independently as any remotely reasonable government would allow, and created a connector that would later inspire USB-C.
> What particularly ircs me is that Apple has acknowledged that USB-C is the superior plug by going all in on their laptops. But they can't let go of all the money they make selling licenses for third party cables on iPhones.
Catch-22; if they change the cable people like you complain that they’re trying to obsolete accessories, and if they don’t change the cable people like you complain that they’re trying to profiteer off of accessories.
Since the user didn't specify a format, and the website didn't specify a format, the iPhone needs to guess something. Seems to me it should guess the format that's most likely to work, not the one only a tiny number of devices support.
If an exception is thrown and not caught, the software should stop doing anything.
And yea - I agree that flash is dead at this point and I'm quite happy it's gone. Apple actually contributed significantly to the death of flash based advertisements and there is nothing in the world I hated more than those.
Writing extra code to delete a file in a catch block doesn't seem like something someone trying to account for failure scenarios would do, it's much more likely that the data was living in memory and no thought was put into failure scenarios in that part of the code.
"Give me the underlying data, just as it is. You may or may not understand what it is, but I'm asking you to pretend that you don't, because I definitely don't understand what it is. I'm acting as a courier on behalf of a recipient who wants whatever you give me. All they told me was to get it from you. Please don't try to guess why they want it, or to prepare it for them in some way. Their motivations are beyond our understanding. They just want it. They want what you have, the way you currently have it. Do as little to it as possible, because anything you do may be counter-productive to their unknowable designs."
This is, for one thing, the use-case of file-sharing websites. If you upload something to e.g. MEGA, or WeTransfer, you're doing that in order for something further to happen to it on the other side. The other side may or may not have wanted the file in its original format, but that question is up to them, not up to the sender. The job of a "dumb pipe" file-transfer service, is to take what it's given, and losslessly pass it on to the recipient, so that further steps can happen. And, as such, it's also a responsibility of a file-transfer service to ask the User-Agent to also send the file on to it losslessly, because in this case the User-Agent is also acting as part of the "dumb pipe" transfer process.
Let me put it this way: if my photos were not saving correctly, and someone at Apple asked me to file a Radar ticket and attach such a mis-encoded photo to the ticket... how would the Radar web-app express the intent of "I want the stupid mis-encoded file that you-the-device are using to store what you think is a Photos photo"? Well, our legacy convention is that it would express that intent through `accept="⋆/⋆"`. (Or a lack of an `accept` header at all.)
Note that this is different from an `accept` attribute like "image/⋆". In that case, we know something—we know that the recipient we're acting as courier has the intent to use the uploaded file as an image—so both the mis-encoded file, and maybe HEIC files, are probably bad candidates. One should be filtered out as an upload candidate; the other should maybe be transcoded (just like a RAW camera file would be.)