 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 01/08/2015 12:09 AM, Jim Henderson wrote:
> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>
>> Selling "support" also works. Provided you have the staff to actually
>> deliver support.
>
> The problem with this is that if you're selling support, your product is
> poorly designed and difficult to use.
>
> If you're a software company that depends on support and training as
> bottom-line revenue figures, you're doing software wrong IMHO.
Heh. Well there is that... ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2015-07-31 19:09, Jim Henderson a écrit :
> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>
>> Selling "support" also works. Provided you have the staff to actually
>> deliver support.
>
> The problem with this is that if you're selling support, your product is
> poorly designed and difficult to use.
>
> If you're a software company that depends on support and training as
> bottom-line revenue figures, you're doing software wrong IMHO.
>
You're saying a oil-rig management system, or an MRI control system
shouldn't require training?
I agree that if you're selling 3D-tictactoe-as-a-Service, and expect
people to call you for support, you may have a problem, but complex
software such as ERPs, or even industry-grade CAD systems _should_
require some level of training to install and operate properly.
> Jim
>
--
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/* flabreque */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/* @ */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/* gmail.com */}camera{orthographic location<6,1.25,-6>look_at a }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 01.08.2015 um 01:09 schrieb Jim Henderson:
> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>
>> Selling "support" also works. Provided you have the staff to actually
>> deliver support.
>
> The problem with this is that if you're selling support, your product is
> poorly designed and difficult to use.
>
> If you're a software company that depends on support and training as
> bottom-line revenue figures, you're doing software wrong IMHO.
Support := help with operating the software in conditions not
anticipated during the design.
Nothing wrong with that in my book, provided the company isn't shifting
costs from the design phase to the support phase.
Sample case: A big company I worked for some day realized that they were
growing out of the version control system they were using; apparently
the system was designed (and purchased) for a much smaller number of
projects and consequently a much smaller number of changes than what was
by now happening at that company, and was now running out of IDs for the
changes. The software company provided support by shipping a
custom-tailored build of the software using larger data fields for those
IDs.
Also, there are types of software - most notably any non-trivial
business software - where unanticipated operating conditions are the
norm; no two companies of any significant size have the same business
processes. Therefore, standard business software is designed to be
adapted for each individual customer, but this adaptation process is
non-trivial because of the flexibility the software offers.
Some software companies seem to be able to provide this level of support
free of charge, but I have no problem with software companies covering
the costs for this type of post-sale development by selling service
agreements.
But of course if you define support := user-driven on-demand training of
individual end users in how the software is supposed to work, then yes,
if that's your business model then you're certainly doing something wrong.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/1/2015 12:09 AM, Jim Henderson wrote:
> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>
>> Selling "support" also works. Provided you have the staff to actually
>> deliver support.
>
> The problem with this is that if you're selling support, your product is
> poorly designed and difficult to use.
>
> If you're a software company that depends on support and training as
> bottom-line revenue figures, you're doing software wrong IMHO.
>
To add to Francois and Clipa’s comments (I hope I got the apostrophe right).
ERP software is initially configured with the help of the customer’s
management and key users. They know what they want and outline their
requirements. By the time the blueprint is designed, and implemented.
The customer knowns more about how the software works and often redefine
their requirements. This can extend the implementation to the extent it
will never be finished. (At BASF the German branch took 10 years on a
pilot project and they were still not finished.) So there is generally a
“Freeze” where there are no more changes allowed. After the “Go Live”
the support company will make the changes wanted. This can be quite
extensive.
These programs are quite complex and it is not normal for the company to
do them as they generally do not have the expertise. If the company is
regulated by, say the FDA, Financial authorities, Nuclear regulators
etc. It has to be done by an authorised external company.
User support is almost a freebie.
--
Regards
Stephen
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Aug 2015 10:37:20 -0400, Francois Labreque wrote:
> Le 2015-07-31 19:09, Jim Henderson a écrit :
>> On Fri, 31 Jul 2015 19:47:14 +0100, Orchid Win7 v1 wrote:
>>
>>> Selling "support" also works. Provided you have the staff to actually
>>> deliver support.
>>
>> The problem with this is that if you're selling support, your product
>> is poorly designed and difficult to use.
>>
>> If you're a software company that depends on support and training as
>> bottom-line revenue figures, you're doing software wrong IMHO.
>>
>>
> You're saying a oil-rig management system, or an MRI control system
> shouldn't require training?
Of course not. There are things relating to the system that are not
about the system itself.
What I am saying is that if your UI is so complex that it needs a guide
or a training class, then your UI is not properly designed.
> I agree that if you're selling 3D-tictactoe-as-a-Service, and expect
> people to call you for support, you may have a problem, but complex
> software such as ERPs, or even industry-grade CAD systems _should_
> require some level of training to install and operate properly.
No, training is required for the job. In order to use a CAD system to
design aircraft properly, for example, you need to understand aircraft
design.
Using the UI should be intuitive to someone with the necessary skills.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Aug 2015 18:21:26 +0200, clipka wrote:
> Support := help with operating the software in conditions not
> anticipated during the design.
In software these days, design tends to follow implementation - which is
backwards.
That's what leads to a lot of broken UIs. No design before
implementation - the design comes with the implementation, and it follows
the implementation rather than having a UX plan before the implementation
starts.
> Nothing wrong with that in my book, provided the company isn't shifting
> costs from the design phase to the support phase.
Indeed, that's the problem I'm talking about - but with the added bit of
"pay us to tell you how to use it properly".
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sat, 01 Aug 2015 19:29:40 +0100, Stephen wrote:
> By the time the blueprint is designed, and implemented. The customer
> knowns more about how the software works and often redefine their
> requirements. This can extend the implementation to the extent it will
> never be finished.
Very true.
Two words you mention at the start, though, are not often enough included
in software development: "blueprint" and "design".
Specifically, user interaction design.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 03.08.2015 um 02:50 schrieb Jim Henderson:
> On Sat, 01 Aug 2015 18:21:26 +0200, clipka wrote:
>
>> Support := help with operating the software in conditions not
>> anticipated during the design.
>
> In software these days, design tends to follow implementation - which is
> backwards.
No, actually that's where the software industry started. The truth is
that things have gotten a tad better since then.
(Except in the domain of Open Source Software, where development is
still driven by the developers rather than the users.)
> That's what leads to a lot of broken UIs. No design before
> implementation - the design comes with the implementation, and it follows
> the implementation rather than having a UX plan before the implementation
> starts.
This thread started about Microsoft, didn't it?
You're certainly looking in the wrong direction there. Just look at
Office 2010, and the loads of UI analysis and research went into it. Or
Microsoft's primary programming language and environment, Visual Studio
and C#, which in my book is as close as anyone has ever gotten to a
programmer's dream.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 03 Aug 2015 09:10:00 +0200, clipka wrote:
> Am 03.08.2015 um 02:50 schrieb Jim Henderson:
>> On Sat, 01 Aug 2015 18:21:26 +0200, clipka wrote:
>>
>>> Support := help with operating the software in conditions not
>>> anticipated during the design.
>>
>> In software these days, design tends to follow implementation - which
>> is backwards.
>
> No, actually that's where the software industry started. The truth is
> that things have gotten a tad better since then.
Yes, that is where it started, but it's still a poor way to build
products.
> (Except in the domain of Open Source Software, where development is
> still driven by the developers rather than the users.)
Very much so.
>> That's what leads to a lot of broken UIs. No design before
>> implementation - the design comes with the implementation, and it
>> follows the implementation rather than having a UX plan before the
>> implementation starts.
>
> This thread started about Microsoft, didn't it?
>
> You're certainly looking in the wrong direction there. Just look at
> Office 2010, and the loads of UI analysis and research went into it. Or
> Microsoft's primary programming language and environment, Visual Studio
> and C#, which in my book is as close as anyone has ever gotten to a
> programmer's dream.
I'm talking about interaction design, not design done by developers.
An interesting read - The Inmates are Running the Asylum, by Alan Cooper
- describes the problem more fully.
Jim
--
"I learned long ago, never to wrestle with a pig. You get dirty, and
besides, the pig likes it." - George Bernard Shaw
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Le 03/08/2015 09:10, clipka a écrit :
> Office 2010, and the loads of UI analysis and research went into
> it.
When you are used to WinWord since 1995, Office 2010 is a PITA for
usual edition: the style short-cut/rolling selector does not list all
the available style, you have to expand it full size (as a size panel)
and it's not the same list. And the menus are all
"redesigned/reorder"... Reorganising windows of 2 documents is
difficult to have them side by side (and it engages "sync-scroll",
always, which is good for different versions but suck for document
that are not identical but you want to read side by side (such as High
level & low level design))... 3 windows side by side ? forget it, no
more possible (or give me the way to do it: yes, stacked you can have,
but not left/center/right, using the mouse would be cheating )
And installation sticks to activate auto-correction and other
misbehaviour. (I know how to get «, I do not want Word to replace my
input of " with « because it's more fancy... especially when it's
code). And auto-capitalisation of first letter at start of sentence is
bad also for code.
The docx format is painful also: being a zipped xml, but without
internal management of versions, it is hardly compatible with any DCMS
(well, unless each version/commit become a blob by itself, with the
associated problems of disk space and bandwidth).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iJwEAQEIAAYFAlW/js0ACgkQhKAm8mTpkW0ICAP/ew0UtZKcuxUBzUwZrilmbuhA
fgpbMWQWbJKAcU+pMpzvj2vRvQOpu5dMdPX3zyOnmtiaN/fMsU08uY749qW0N3dz
7eMPqdr4n0ePbBo+OYVLMawX9MAMsDhjaOqxwKkfpzayrFO+5/GubhtVtEv6ubBa
hSYlT4zw2i95hA3cl04=
=emCB
-----END PGP SIGNATURE-----
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
