[feedhenry-dev] mobile client or mobile app

Wed Dec 13 15:59:47 UTC 2017

I thought this was interesting.

Chris Shinn (UX) came up with the term 'Mobile Client Build' in UI mockups
for mobile apps on the OpenShift overview screen.
This was to make it obvious we're talking about 'Mobile' builds rather than
typical S2I or Docker builds.

[image: Inline images 1]

On 30 November 2017 at 14:13, Matthias Wessendorf <mwessend at redhat.com>
wrote:

> I like that - and is similar to UPS terminology :)
>
>
>
> On Thu, Nov 30, 2017 at 2:23 PM, John Frizelle <jfrizell at redhat.com>
> wrote:
>
>> perhaps "construct" instead of "container configuration"
>>
>> MobileClient: A construct that represents the overall mobile application
>> on OpenShift (eg MobileHR)
>>
>>
>> --
>> John Frizelle
>> Chief Architect, Red Hat Mobile
>> Consulting Engineer
>>
>> mobile: *+353 87 290 1644 <//+353872901644>*
>> twitter:* @johnfriz*
>> skype: *john_frizelle*
>> mail: *jfrizell at redhat.com <jfrizell at redhat.com>*
>>
>>
>>
>>
>> On 30 November 2017 at 11:48, Matthias Wessendorf <mwessend at redhat.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Nov 30, 2017 at 12:05 PM, Paul Wright <pwright at redhat.com>
>>> wrote:
>>>
>>>> last comment, then I'll stop (promise):
>>>>
>>>> Let's go with MobileClient, as discussed below, but take a bit more
>>>> time about the definition.
>>>>
>>>> I think the definition for PushApplication is great in the context of
>>>> UPS, but with MCP, we're trying to explain an item that is front and
>>>> center, and that the user might misunderstand, or not act as expected.
>>>>
>>>> Can we be more explicit and give an example?
>>>>
>>>> - MobileClient: A container configuration that represents the overall
>>>> mobile application on OpenShift (eg MobileHR)
>>>>
>>>
>>> container ... hrm - not sure -  that's also misleading... ?!
>>>
>>>
>>>
>>>>
>>>>
>>>> Paul
>>>>
>>>> On 11/30/2017 10:26 AM, Matthias Wessendorf wrote:
>>>>
>>>> +1 on something like "logical construct / logical representation"   -
>>>> and right UPS has also had some naming struggles :)
>>>>
>>>> On Thu, Nov 30, 2017 at 11:11 AM, David Martin <davmarti at redhat.com>
>>>> wrote:
>>>>
>>>>> The term 'Resource' may not suit as it has a meaning in the Kubernetes
>>>>> world.
>>>>> Any object that kubernetes exposes an API for is a resource e.g.
>>>>> Secrets, Pods, Deployments are all resources.
>>>>>
>>>>> In UPS, there's the idea of a 'Push Application', defined here [1]
>>>>> "PushApplication
>>>>> A logical construct that represents an overall mobile application"
>>>>>
>>>>> I don't see any problem with giving it a name like 'Mobile Client' and
>>>>> calling it out in terminology in a similar manner
>>>>> "MobileClient
>>>>> A logical construct that represents an overall mobile application"
>>>>>
>>>>> [1] https://aerogear.org/docs/unifiedpush/ups_userguide/inde
>>>>> x/#_useful_terminology
>>>>>
>>>>> On 29 November 2017 at 09:42, Paul Wright <pwright at redhat.com> wrote:
>>>>>
>>>>>> and that conversation makes me think we need to be more descriptive,
>>>>>> eg
>>>>>>
>>>>>> Mobile App Resource Client (MARC)
>>>>>>
>>>>>> Paul
>>>>>>
>>>>>> On 11/29/2017 09:38 AM, Craig Brookes wrote:
>>>>>>
>>>>>> Spoke with Paul offline. And he thought we were referring to mobile
>>>>>> app through out our docs. So to clarify I meant with the context of the mcp
>>>>>> UI and CLI.
>>>>>>
>>>>>> On Mon, Nov 27, 2017 at 11:49 AM, Paul Wright <pwright at redhat.com>
>>>>>> wrote:
>>>>>>
>>>>>>> It seems to me that to tackle the mobile market, we should embrace
>>>>>>> the lingua franca, and the one word that unites mobile,cell phone,
>>>>>>> smartphone, handys, etc is 'App'
>>>>>>>
>>>>>>> Paul
>>>>>>> my original draft reply:
>>>>>>>
>>>>>>> Mondays...
>>>>>>>
>>>>>>> Let's fix everything <sigh>
>>>>>>>
>>>>>>> I'm not against this change, but would like to throw in a note of
>>>>>>> caution:
>>>>>>>
>>>>>>> 1. I don't think OpenShift are really pushing the term apps. Sure,
>>>>>>> there's a command, and even some doc references (
>>>>>>> https://access.redhat.com/documentation/en-us/openshift_ent
>>>>>>> erprise/3.2/html/installation_and_configuration/install-conf
>>>>>>> ig-imagestreams-templates#creating-instantapp-templates), but would
>>>>>>> like to check with them before assuming that's deliberate. In my mind,
>>>>>>> their term of choice is Application, a bit more of an enterprisey term.
>>>>>>>
>>>>>>> 2. Does "Mobile Clients" solve a problem? we already have a
>>>>>>> generation of ppl saying "there's an app for that", do we want to embrace
>>>>>>> that or swim upstream? what about when there's a web ui to something, we
>>>>>>> used to bundle mobile and web into the term 'client app'.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 11/27/2017 11:03 AM, Jason Madigan wrote:
>>>>>>>
>>>>>>> Deep thoughts this early in the week. App is quite a loaded term
>>>>>>> alright, particularly in an OpenShift context, so I think Mobile Client may
>>>>>>> be a clearer distinction.
>>>>>>>
>>>>>>> Looping in our wordsmith Paul who may have other ideas.
>>>>>>>
>>>>>>> On Mon, Nov 27, 2017 at 9:44 AM, Craig Brookes <cbrookes at redhat.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Was thinking about terminology . We have been using the term mobile
>>>>>>>> app, but I wonder would it be clearer to use the term mobile client
>>>>>>>> instead.
>>>>>>>> The main reason for this is that app can mean a server side
>>>>>>>> component (in OpenShift there is the new-app command for example). I think
>>>>>>>> it would make a clearer distinction. Another example is around the word
>>>>>>>> build. When you do an app build in OpenShift it normally produces a docker
>>>>>>>> image and a running server / app. I think using the the term mobile client
>>>>>>>> build makes it clearer what is happening.
>>>>>>>>
>>>>>>>> Just a thought for a Monday morning.
>>>>>>>>
>>>>>>>> --
>>>>>>>> Craig Brookes
>>>>>>>> RHMAP
>>>>>>>> @maleck13 Github
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> feedhenry-dev mailing list
>>>>>>>> feedhenry-dev at redhat.com
>>>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Jason Madigan
>>>>>>> Engineering Manager, Red Hat Mobile
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Craig Brookes
>>>>>> RHMAP
>>>>>> @maleck13 Github
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> feedhenry-dev mailing list
>>>>>> feedhenry-dev at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> David Martin
>>>>> Red Hat Mobile
>>>>> Twitter: @irldavem
>>>>> IRC: @irldavem (feedhenry, mobile-internal)
>>>>>
>>>>> _______________________________________________
>>>>> feedhenry-dev mailing list
>>>>> feedhenry-dev at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Project lead AeroGear.org
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Project lead AeroGear.org
>>>
>>> _______________________________________________
>>> feedhenry-dev mailing list
>>> feedhenry-dev at redhat.com
>>> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>>>
>>>
>>
>
>
> --
> Project lead AeroGear.org
>
> _______________________________________________
> feedhenry-dev mailing list
> feedhenry-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/feedhenry-dev
>
>

-- 
David Martin
Red Hat Mobile
Twitter: @irldavem
IRC: @irldavem (feedhenry, mobile-internal)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171213/4582e814/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo.png
Type: image/png
Size: 11472 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171213/4582e814/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 70585 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/feedhenry-dev/attachments/20171213/4582e814/attachment-0001.png>