search

particle-iot / spark-setup-ios

(DEPRECATED) Spark device setup library - Soft AP Cocoapod/Carthage lib for iOS
Apache License 2.0
19 stars 25 forks source link

Customizing Text Content #54

Open shaskins opened 7 years ago

shaskins commented 7 years ago

I'm curious if there is a way to customize the text written during the wizard setup process, i.e "Plug in your Particle device to power it on". There are specific variables exposed that can be changed such as deviceName, productImage etc, but can we change the entire string? While most of the default text is good, I'm curious if we can customize it more to suit our customers.

idokleinman commented 7 years ago

There are several text customization points as you implied, if you require deeper changes feel free to modify the setup.storyboard file as you please

shaskins commented 7 years ago

Much appreciated!

shaskins commented 7 years ago

Out of curiousity, is there any plans to implement allowing all of the strings to be edited without having to go in and modify the setup.storyboard file? Is there a reason they aren't all exposed to be changed?

And another question regarding the existing listenModeLEDColorName, I see it written in the documentation as something that you can change, even though it doesnt work. Which makes sense because in the storyboard file it looks like this: text="The on-board LED should be blinking blue. If not, hold the {mode button} for 3 seconds"

As you can see the part about blinking blue isn't something you can insert in, even though the documentation seems to say that you can. You can see the part where the NSString modeButtonName goes though.

gitjoost commented 7 years ago

@idokleinman: is modifying setup.storyboard the way to go really? With every library update this would be overwritten.

idokleinman commented 7 years ago

I do agree that modifying the storyboard itself is a makeshift solution. I think the best way to go is to add some real customization points - basically creating an addressable UILabel in the viewcontroller requiring the modification, adding it to the Customization class and then submitting PR so it can be incorporated in future releases of the SDK. That's my suggestion.

Another option which is related is to export ALL the strings in the setup to an external file, that could also be used for localization in the future and allow the developers to modify this file. Usually done for strings in the code files but could also apply to storyboard strings.

gitjoost commented 7 years ago

@idokleinman: Please consider that the on-boarding API becomes part of the entire App and must therefore 'fit' in the App. I.e., it needs to look like one seamless part. That means that all aspects of what is being shown ought to be customizable; font sizes, color, types, positioning, pictures, buttons etc. you name it. To solve this through 'customization points' as you refer to it seems not practical to me.

When I first looked into this aspect of the lib I was a bit taken aback modding the storyboard (since it is part of the lib) But having access to the storyboard allows for all possible visual customization. Since the current storyboard is part of the lib it would be better to have a custom storyboard that is referenced from the library. The mods I made thus far to my solution only required modding the storyboard and no code (with exception to a few minor wiggles). So if we had the custom storyboard referenced from the lib, it is possible to do all necessary mods. I would do away with all code based customizations and do all customizations through the referenced storyboard.

What may complicate things a bit if the flow of the on-boarding process needs to be customized also. For my current purposes I do not have hard requirements for that ... yet... Although I do have some customers confused by the process (which is very techie for most folks) and therefore injections of a few pages/links with additional help could be handy.

Localization would be made a bit easier if all customization is done through the storyboard as this would mean just one in/export step vs two if code is involved also. Obviously, the rest of the app would need localization also which will require its own methods.

idokleinman commented 7 years ago

This is escalating to be a very very deep rabbit hole IMO, not sure if all developers need SO much control over every pixel in setup, to the point of changing the flow itself.

Another option, that adheres to what you're suggesting, is Particle providing "setup library" that comes with no mobile setup UI/UX whatsoever, like the Cloud SDK - only a required set of function calls in a certain order, i.e.: detect photon(), scan wifi(), configure wifi(), connect() and the developer will have to (re)build the setup flow/experience himself to his liking. Not sure that's really ideal. Maybe the setup functions could be stripped out from the setup flow so developers requiring FULL customization, like yourself, can do that.

gitjoost commented 7 years ago

I can't see it to be such a deep rabbit hole but it is a shift from the current concept. Perhaps my proposal is flawed (happened before :-) but I would expect that anyone/company in the business of delivering end-user solutions will want to own the entire experience. In all products I have been part of this was the case. But hey, who am i.

The "setup-lib without UI/UX" and only particular hooks into the process would be a great step.

Question: how does your company make decisions for changes like these? Is there a customer focus group? I'd hate to push for my personal stuff if nobody cares but I'd equally hate it if what I push is really where it needs to be and nobody listens...

Anyway, as said, I am already partially going this route. If I have time and it makes sense, I will attempt to generalize my changes and perhaps fork the lib for others to use.