I'm a little surprised to see DED advertising a Google program, but it looks like it can certainly help out some of the developers who read AI.
Considering there's only 3 paragraphs (aka, run-on sentences) actually talking about Google Web Designer, I'd hardly call it an advertisement. The rest is the typical Dilger, "Why Google sux and Apple rox" BS.
It's funny hearing NFC described as a failure when Disney is making a huge push with it at their parks. Everything is using NFC (park admission, payments, room keys, even the refillable cups). Not bad for a "failed" tech.
Considering there's only 3 paragraphs (aka, run-on sentences) actually talking about Google Web Designer, I'd hardly call it an advertisement. The rest is the typical Dilger, "Why Google sux and Apple rox" BS.
It's funny hearing NFC described as a failure when Disney is making a huge push with it at their parks. Everything is using NFC (park admission, payments, room keys, even the refillable cups). Not bad for a "failed" tech.
You use NFC on your phone to refill a cup at a Disney property?
The chip is in the cup. So the soda machine will only activate when a cup with an active chip is near it.
If you are then well aware that the technology is not used in the capacity as it has been in a phone, where it has failed to gain real traction due to poor planning and implementation (among other reasons) why make a blanket statement implying the technology is great everywhere simply because it's effective somewhere?
Besides the very limited number of fountain machines Disney has to support with technology it's not querying a transaction server to remove funds the same it would have to be designed to support nearly every vendor if this were to be successful for payments. Your example is simply too limited to be proof that Android's NFC is somehow a success by this weak comparison.
BTW, and perhaps I should have opened with this, are you sure there cups are using NFC and not an RFID tag? That latter is a lot cheaper and seems just as effective for this type of transaction.
Finally, the most successful example of which I'm aware is Japan's FeliCa. It's not quite modern NFC but it's more advanced than good ol' RFID. Many of its aspects were used for creating the modern NFC standard.
The app is not native, it does not follow Apple HIG, looks like crap, and worst of all, it stealth installs Chrome. It doesn't give you the choice, it just installs the pile of crap.
The app is not native, it does not follow Apple HIG, looks like crap, and worst of all, it stealth installs Chrome. It doesn't give you the choice, it just installs the pile of crap.
You must not be a web developer because if you were you would obviously have Chrome already installed as it is the most widely used browser which a developer would normally be interested in testing their code with.
Not sure what you mean by not native. Can you explain?
Agree about the Apple HIG. The appearance is not Apple inspired clearly. Looks more like Adobe Photoshop CC.
The functionality of the application is better than I've seen from any other HTML5 CSS3 authoring environment in terms of drag and drop, preview/code mode, with excellent prebuilt components, etc. I've tried others including iAd but this one seems the most intuitive and user friendly from my perspective.
Well, Im actually a developer, but I do inspect the stuff I install, so thats why I discovered the drive-by-install of Chrome. Would not any real developer be critical to what she installs on her workstation? Any app that sneaks in other apps without asking is breaching the trust an user would have towards a developer, so no, I dont trust Google anymore.
When you can't clearly see the app is not native for Mac, you are not much of a developer yourself. No app developed with Xcode would have a menu bar within the window itself. The menubar is supposed to be on top of the screen, not somewhere else. Thats first. Second, the fonts used in the app, app-menus and so on are not as they are supposed to be. The HIG is made for a reason, this is just a quick and dirty ported linux app. It doesn't use Cocoa, but Chromium for the UI.
When you can't clearly see the app is not native for Mac, you are not much of a developer yourself. No app developed with Xcode would have a menu bar within the window itself.
Thanks for the explanation as to how you define native applications. I never considered Xcode as being a requirement. I could write an application in any language I like and compile it on a Mac using GCC and then run it natively. It doesn't even need an interface at all and could even be run from the command line just like so many native Apple ported applications from BSD to OS X do.
From Wikipedia:
Quote:
(Native applications) Machine code or machine language is a system of instructions and data executed directly by a computer's central processing unit.
Does not matter how you write the app, but for it to be a proper native Mac app, it would conform to the HIG, and use cocoa. You could write it in binary on a paper napkin for what I care, just as the app gives the proper feel. If you want, we can start to discuss the smallest details of an app being native or not, if you use the Wikipedia definition of "machine code" or "machine language" as a requirement for an app to be native, almost none of the Mac apps are native, as they are compiled during runtime. Most apps are just pre-compiled.
But thats not the point here, there are two points: 1. They install crap whitout any warning. 2. They have not provided a proper Mac tool. It would never be accepted in the App Store.
There are many Unix Executable Files in OS X however. On my Mac there are 4,726 of them.
I agree with you about the GWD app as being non-compliant with Apple HIG but that does not really concern me too much. I'm more interested in what it can do than what it looks like. Almost all of the code writing I do is php/js/css for web so having a quick method to generate some HTML5 code is a welcome feature for me.
Comments
Considering there's only 3 paragraphs (aka, run-on sentences) actually talking about Google Web Designer, I'd hardly call it an advertisement. The rest is the typical Dilger, "Why Google sux and Apple rox" BS.
It's funny hearing NFC described as a failure when Disney is making a huge push with it at their parks. Everything is using NFC (park admission, payments, room keys, even the refillable cups). Not bad for a "failed" tech.
You use NFC on your phone to refill a cup at a Disney property?
You use NFC on your phone to refill a cup at a Disney property?
The chip is in the cup. So the soda machine will only activate when a cup with an active chip is near it.If you are then well aware that the technology is not used in the capacity as it has been in a phone, where it has failed to gain real traction due to poor planning and implementation (among other reasons) why make a blanket statement implying the technology is great everywhere simply because it's effective somewhere?
Besides the very limited number of fountain machines Disney has to support with technology it's not querying a transaction server to remove funds the same it would have to be designed to support nearly every vendor if this were to be successful for payments. Your example is simply too limited to be proof that Android's NFC is somehow a success by this weak comparison.
BTW, and perhaps I should have opened with this, are you sure there cups are using NFC and not an RFID tag? That latter is a lot cheaper and seems just as effective for this type of transaction.
Finally, the most successful example of which I'm aware is Japan's FeliCa. It's not quite modern NFC but it's more advanced than good ol' RFID. Many of its aspects were used for creating the modern NFC standard.
The app is not native, it does not follow Apple HIG, looks like crap, and worst of all, it stealth installs Chrome. It doesn't give you the choice, it just installs the pile of crap.
The app is not native, it does not follow Apple HIG, looks like crap, and worst of all, it stealth installs Chrome. It doesn't give you the choice, it just installs the pile of crap.
You must not be a web developer because if you were you would obviously have Chrome already installed as it is the most widely used browser which a developer would normally be interested in testing their code with.
Not sure what you mean by not native. Can you explain?
Agree about the Apple HIG. The appearance is not Apple inspired clearly. Looks more like Adobe Photoshop CC.
The functionality of the application is better than I've seen from any other HTML5 CSS3 authoring environment in terms of drag and drop, preview/code mode, with excellent prebuilt components, etc. I've tried others including iAd but this one seems the most intuitive and user friendly from my perspective.
Well, Im actually a developer, but I do inspect the stuff I install, so thats why I discovered the drive-by-install of Chrome. Would not any real developer be critical to what she installs on her workstation? Any app that sneaks in other apps without asking is breaching the trust an user would have towards a developer, so no, I dont trust Google anymore.
When you can't clearly see the app is not native for Mac, you are not much of a developer yourself. No app developed with Xcode would have a menu bar within the window itself. The menubar is supposed to be on top of the screen, not somewhere else. Thats first. Second, the fonts used in the app, app-menus and so on are not as they are supposed to be. The HIG is made for a reason, this is just a quick and dirty ported linux app. It doesn't use Cocoa, but Chromium for the UI.
When you can't clearly see the app is not native for Mac, you are not much of a developer yourself. No app developed with Xcode would have a menu bar within the window itself.
Thanks for the explanation as to how you define native applications. I never considered Xcode as being a requirement. I could write an application in any language I like and compile it on a Mac using GCC and then run it natively. It doesn't even need an interface at all and could even be run from the command line just like so many native Apple ported applications from BSD to OS X do.
From Wikipedia:
Does not matter how you write the app, but for it to be a proper native Mac app, it would conform to the HIG, and use cocoa. You could write it in binary on a paper napkin for what I care, just as the app gives the proper feel. If you want, we can start to discuss the smallest details of an app being native or not, if you use the Wikipedia definition of "machine code" or "machine language" as a requirement for an app to be native, almost none of the Mac apps are native, as they are compiled during runtime. Most apps are just pre-compiled.
But thats not the point here, there are two points: 1. They install crap whitout any warning. 2. They have not provided a proper Mac tool. It would never be accepted in the App Store.
EOD.
...almost none of the Mac apps are native, as they are compiled during runtime. Most apps are just pre-compiled.
I'm pretty sure they are binary executables.
Which complier is performing this runtime compilation?
Read the Objective-C documentation, for example the Objective-C Runtime Programming Guid, and you will understand what I just said.
Im done with this discussion, wont check in anymore, have fun.
Read the Objective-C documentation, for example the Objective-C Runtime Programming Guid, and you will understand what I just said.
Im done with this discussion, wont check in anymore, have fun.
Ok good info. I never used it. I also found this website that I think is pretty good as further reading.
http://cocoasamurai.blogspot.com/2010/01/understanding-objective-c-runtime.html
There are many Unix Executable Files in OS X however. On my Mac there are 4,726 of them.
I agree with you about the GWD app as being non-compliant with Apple HIG but that does not really concern me too much. I'm more interested in what it can do than what it looks like. Almost all of the code writing I do is php/js/css for web so having a quick method to generate some HTML5 code is a welcome feature for me.