Forum Posts Feed
Teaser - Polywick Story Server
< Next Topic | Back to topic list | Previous Topic >
Pages: ‹ First < 12 13 14 15 16 17 >
Posted by tightbeam
Feb 26, 2019 at 11:46 PM
When are you going to reply to the questions that people have asked about your “software”? Instead of providing links that prove absolutely nothing about whether there actually *is* software, you could have replied to the questions, and done a bit of damage control. You don’t seem to understand - or maybe you’re too young to understand - that your attitude on this forum is harming your venture. In fact, when you google “Polywick Story Server”, the second result is this very thread. (The first result is a thread on DonationCoder that puts you in an equally poor light.)
Now think carefully: is this thread, and in particular your immature replies to legitimate questions, what you want prospective customers to read when they search for “Polywick Story Server”?
PS. Do you know what “slander” means? It’s not what you apparently think it is. And you’re not going to sue anyone. Get real.
PPS. My advice - even though you didn’t ask for it, and probably don’t want it - is to not post here again until you’re able to provide a download link to an alpha or beta version of your software. That’s the only way you’ll change the opinions that unfortunately have calcified against you. Make the naysayers eat their words!
Polywick Studio wrote:
>Our business address is here on the website.
>You can’t see it or are you intent on slandering us?
>https://www.polywickstudio.com/contact
>
>
>Our company is registered (SEC CS201802998) and you can search for it
>here:
>https://secexpress.ph/application-form
>
>
>There’s documentation on code-signing already -
>https://storyserver.polywickstudio.ph/ss/security-issues.html
>
>
>Please stop your lies and fabrications. You are telling nonsense.
>
Posted by Lothar Scholz
Feb 27, 2019 at 09:34 AM
@Bobby Parker
Well this is the difference between a desktop guy and the server guy. I know both but i’m very biased towards desktop development because i studied computer science and labour psychology. And for me the datastructures don’t end at the database level.
In the 90ths the common rule was that creating the GUI takes 80% of the time. I would say that nowadays its 95%. Because the graph database is something you can buy for money or download as open source. But most of them don’t work well for Desktop Apps. If you try to embedd Postgresql into your app then i wish you good luck and a large enough support team to handle the incoming calls (been there, done that).
But the main problem is that a modern Ecco would need much more and different then the old one.
That was the reason why i asked about the multiline column texts. It’s just the most innocent question to find out if he is wrapping just an entry control into a treelist control or really doing something new that only looks old.
Posted by Pierre Paul Landry
Feb 27, 2019 at 01:03 PM
Lothar Scholz wrote:
>In the 90ths the common rule was that creating the GUI takes 80% of the time. I would say that nowadays its 95%. (...)
>But the main problem is that a modern Ecco would need much more and different than the old one.
>That was the reason why i asked about the multiline column texts. It’s just the most innocent question to find out if he is wrapping just an entry control into a treelist control or really doing something new that only looks old.
As a developer of InfoQube, heavily inspired by Ecco, I agree 100% with you. The database stuff was dead easy. 99.9% of the work is the UI.
Pierre
IQ Designer
http://www.infoqube.biz
Posted by Bobby Parker
Feb 27, 2019 at 02:35 PM
I usually agree with such statements in general, but I’m forced to disagree here, because the ecosystem around these types of informational traversal has advanced to the point that now browsers have support for wildly many more things than are ‘conventionally known’.
You’re absolutely right that graph databases can be gotten for free, pre-assembled, ready to leap into action. You’re right. Out the box, they’re not much use by themselves. A graph database by itself isn’t even enough for Ecco’s purposes, it’s barely enough to generate a menu system from and drive meaningful navigation. There’s a lot you have to do to add & track the bits of context that need tracking.
EccoPro’s original data storage functions only accepted primitive values (and a handful of custom ‘complex objects’ and enumerations). What *I* would like, is if my organizer/outliner could accept *whatever* I wanted to put into it.
And yeah, that’s been my point too. A ‘new Ecco’, should exceed the functional limits & expectations of the original, to be worth investing in (at the very least, database size limit! That oughta be easy without working hard).
Lothar Scholz wrote:
@Bobby Parker
>
>Well this is the difference between a desktop guy and the server guy. I
>know both but i’m very biased towards desktop development because i
>studied computer science and labour psychology. And for me the
>datastructures don’t end at the database level.
>
>In the 90ths the common rule was that creating the GUI takes 80% of the
>time. I would say that nowadays its 95%. Because the graph database is
>something you can buy for money or download as open source. But most of
>them don’t work well for Desktop Apps. If you try to embedd Postgresql
>into your app then i wish you good luck and a large enough support team
>to handle the incoming calls (been there, done that).
>
>But the main problem is that a modern Ecco would need much more and
>different then the old one.
>That was the reason why i asked about the multiline column texts. It’s
>just the most innocent question to find out if he is wrapping just an
>entry control into a treelist control or really doing something new that
>only looks old.
Posted by MadaboutDana
Feb 27, 2019 at 02:58 PM
Oh dear, it’s sad to see this promising little project mired in such silliness.
I suggest it’s time for us all to step back and reflect on an app that was, in its time, truly revolutionary, but now, alas, has been allowed to go the way of the dodo.
Namely, Blackwell Idealist.
When we first started up in business, I built our first networked admin database using Idealist. Such was the flexibility of this wonderful bibliographic tool and its simple scripting language that this was relatively easy to do for somebody who, at that time, had absolutely no programming experience at all.
We used it (as a fully LAN-capable system) for about 8 years before I finally replaced it with something much more sophisticated and relational (but still nowhere near professional) in FileMaker Pro.
Now I loved Ecco Pro in its day. But technology, as others have already remarked, has moved on - and in particular, so have user interfaces. So: charming as I find the Polywick attempt to recreate Ecco Pro with more modern underpinnings, I’m afraid they lost me at the UI (and especially UX).
I admire all independent developers, especially passionate ones, but sometimes you’ve got to take a big step back from what you’re doing and consider it from a contemporary perspective.
And let’s face it, Idealist was the ultimate in streamlined, futuristic simplicity. Even by modern standards. Whereas Ecco Pro was already looking old-fashioned by 1998 - albeit charmingly so.
Peace and love, everyone!
Bill